Linux segfault: sqlite3_busy_handler

[mark9]

Hi, nice to see some activity going on.

I wanted to try ASP 2 on my machine (Slackware 14.1, 32-bit) but I get segfault early on when running it:

1) Using version 2.0.0.133
2) "Choose Folder Locations" dialogue, click "OK"
3) "AfterShotPro Trial", click "Try Corel AfterShot Pro"
4) Terminal reports "Segmentation fault"

It's reproducable, so I ensured all my settings were clean before future tests:

$ rm -Rf $HOME/.AfterShotPro
$ rm -f "$HOME/.config/Corel/AfterShot Pro.conf"

If I use gdb, I reliably get the following stack trace (and you can see the console log messages prior to the crash)

[...]
2.245: /home/mark/.AfterShotPro/bibbledebug
2.274: Creating main window 
2.301: Starting Catalog Manager 

Program received signal SIGSEGV, Segmentation fault.
0x080af12e in sqlite3_busy_handler ()
(gdb) bt
#0  0x080af12e in sqlite3_busy_handler ()
#1  0x089dc7a3 in DbManager::setupConnection(QSqlDatabase&) ()
#2  0x089dd750 in Database::Database(BString) ()
#3  0x089dfa48 in SimpleDbConnection::open(BString) ()
#4  0x089e6103 in DbManager::init() ()
#5  0x089e8859 in DbManager::instance() ()
#6  0x08b08b60 in ourmain(int, char**) ()
#7  0x08b0a822 in main ()

After the crash, some files are created, but the 'bibbledebug' file mentioned above is not one of them. I can post the "AfterShotPro.log" file content if necessary, but it just ends with the 3 print lines above. Of the other files, one of them is zero in size:

$ ls -l $HOME/.AfterShotPro/rootdb 
-rw-r--r-- 1 mark users 0 Jun  6 18:59 /home/mark/.AfterShotPro/rootdb

and this chimes with the last few bits of activity if I run ASP through an 'strace':

stat64("/home/mark/.AfterShotPro/rootdb", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("/home/mark/.AfterShotPro/rootdb", O_RDWR|O_CREAT|O_LARGEFILE|O_CLOEXEC, 0644) = 10
fstat64(10, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
fstat64(10, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat64("/home/mark/.AfterShotPro/rootdb", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
_llseek(10, 0, [0], SEEK_SET)           = 0
read(10, "", 100)                       = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x37} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault

All libraries etc. are present according to ldd, so it seems I have the right versions of all required libraries and definitely not a basic compatibility problem. I also tried removing ASP's own lib/ files and using the system ones instead, with the same results in the tests above.

I looked to see if anyone on the forum had anything similar, and the above seems to suggest its a bug that should be reported. I'd at least expect a sane message if I'm doing something wrong or if I don't have the required hardware/paths/permissions. I'm interested if anyone else gets this or has a reasonable workaround, and I hope the information above might be useful to developers.

Looking forward to being able to try ASP 2 soon.

Thanks
Mark

[afx]

Is there already an .AfterShotPro directory from AS1? If yes, configure AS2 to use its own directory.

And remove the cache.

cheers
afx

[mark9]

Is there already an .AfterShotPro directory from AS1? If yes, configure AS2 to use its own directory.

Read the post again: I ensured nothing was present at this directory and showed my steps to do so.

[afx]

Sorry, read to fast.
So if you delete the cache and restart the same error shows up again?

cheers
afx

[mark9]

So if you delete the cache and restart the same error shows up again?

Yup, absolutely. The errors and traces above were taken by deleting the .AfterShotPro directory and config file.

[afx]

Just for completeness sake I would try it also with another user id. But I fear it will be the same result.
The sqlite lib is part of AS I assume?
(sitting at a windows box right now so I can't check)

cheers
afx

[mark9]

You're right, logging in as a different UID and a fresh account made no difference. There is a dynamically loaded sqlite, coming in as part of QtWebKit, but it looks like this one is part of ASP itself.

I think I'm out of luck here.

Thanks for the help.

[mark9]

Just an update, in case it's useful to anyone else, I was able to get the program to work by extracting the .deb instead of the RPM. Hopefully I'll get chance to give it a proper road test in the next week or so.