#21 Crash when results for "lysine" query start showing up

[Alexander Ploumistos]

One (or some?) of the wikidata results for lysine causes the program to crash as soon as it appears. If the window is big enough that the problematic molecule appears right away, it crashes immediately; if it is smaller, the crash happens when I scroll down the list. I tried searching for many compounds, but I didn't get a crash with any of the ones I looked up.

I am attaching the program output from when I ran it from a terminal.

Also, I am not sure about the milestone in the bug report, I am using the sources from ~14 hours ago (Molsketch-latest-src.tar.gz in the snapshots directory), is it 0.5.1?

[Hendrik Vennekate]

Hi Alexander,
0.5.1 will do (as a fix version ;) ). I'll check it out.
Best,

Hendrik

[Hendrik Vennekate]

Hm, this looks bizarre. When I try to search for lysine, I had problems parsing one InChI string (as per debug output) and at one point when scrolling down the list, rendering apparently froze the program for a couple of seconds. But it didn't crash.
From your output (thanks for the logs!), it seems that all molecules are read correctly (not necessarily rendered, yet, though) and the crash occurs close to the point when those molecules are assigned to the displayed list. Could you compile with debug settings so that we get those messages also?

Thanks in advance and kind regards,

Hendrik

[Alexander Ploumistos]

Hi Hendrik,

I had just started to download ~1GB of debuginfo packages in order to use gdb, is that going to do?

[Alexander Ploumistos]

I am attaching a gdb backtrace.

The last messages before the crash were these:

Info: ((null):0, (null)) obtained molecule from wikidata: "N6-[(1R)-2-{[(1R)-1-carboxy-2-methylpropyl]oxy}-1-(mercaptomethyl)-2-oxoethyl]-6-oxo-D-lysine" "CC(C)C(C(=O)O)OC(=O)C(CS)NC(=O)CCCC(C(=O)O)N" "1S/C14H24N2O7S/c1-7(2)11(13(20)21)23-14(22)9(6-24)16-10(17)5-3-4-8(15)12(18)19/h7-9,11,24H,3-6,15H2,1-2H3,(H,16,17)(H,18,19)(H,20,21)/t8-,9-,11+/m0/s1" "CC(C)[C@H](C(=O)O)OC(=O)[C@H](CS)NC(=O)CCC[C@@H](C(=O)O)N"
Info: ((null):0, (null)) obtained molecule from wikidata: "N6-[(1S)-2-{[(1R)-1-carboxy-2-methylpropyl]oxy}-1-(mercaptocarbonyl)-2-oxoethyl]-6-oxo-L-lysine" "CC(C)C(C(=O)O)OC(=O)C(C(=O)S)NC(=O)CCCC(C(=O)O)N" "1S/C14H22N2O8S/c1-6(2)10(12(20)21)24-13(22)9(14(23)25)16-8(17)5-3-4-7(15)11(18)19/h6-7,9-10H,3-5,15H2,1-2H3,(H,16,17)(H,18,19)(H,20,21)(H,23,25)/t7-,9+,10+/m0/s1" "CC(C)[C@H](C(=O)O)OC(=O)[C@H](C(=O)S)NC(=O)CCC[C@@H](C(=O)O)N"
Info: ((null):0, (null)) Clearing list of molecules. Count: 0
terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_M_construct null not valid

Thread 1 "molsketch-qt5" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  }

[Alexander Ploumistos]

And a screenshot of the molecules that had appeared when the crash happened.

[Hendrik Vennekate]

Ok, thanks, the molecule in question seems to be "3,4 ene-lysine" (at least that's the one I get on my query after 2-methyl-D-lysine -- which OpenBabel seems to choose to arrage a little differently than on your query result -- interesting... and I thought that was deterministic).
As for the debug: sorry to have you download all those debuginfo packages, I should have probably expressed myself better: after discovering the value of logging, I added a little bit of output every here and there in Molsketch. This helps us somewhat in your output, but unfortunately, it only seems to show "info" level messages. There should be some "debug" level messages (particularly in the process of rendering the InChI strings into actual molecules, which is where the problem seems to be). I'll try to figure out why that is -- so far my assumption was that it was linked to telling qmake to build in "debug" mode (as opposed to "release" mode). Not sure how cmake does that, though.

Thanks and cheers,

Hendrik

[Hendrik Vennekate]

Good news: I got it reproduced on a Fedora-25 VM... Now let's see what causes it.

[Alexander Ploumistos]

Starting with F27, debuginfo and debugsource have been split into separate subpackages, so if you tried debugging it in F27 or rawhide, you wouldn't need to download so much stuff. Also begining in F27, you can install debuginfo packages in parallel.

As long as you use the packages from copr, dnf knows how to handle everything.

[Hendrik Vennekate]

Ok, now it gets clearer: admittedly, the implementation of the Wikidata query was a little "proof-of-concept" in quality. One thing that stuck out was that OpenBabel expects InChI strings to be prefixed with "InChI=". The vast majority of entries in the Wikidata database, e.g. n-hexane, however, are not prefixed like that. The fix is easy, of course: just prepend the query result accordingly.
Now, it turns out that acetyllysine is an exception to that rule -- the InChI string there is already prepended with "InChI=". For reasons I have not fully understood (nor do we really need to), the particular version of OpenBabel on Fedora 25 (2.3.90-0.11.20160216git3a63a98) seems to not handle that particularly gracefully but instead throws a std::logic_error. The OpenSUSE version (2.3.1-something...) seems not to be affected (I haven't checked if it succeeds in rendering the molecule, though).
At any rate, I'm just going to add a check whether the string is already prefixed or not. Fix should be done later today.

As for the debugging, it seems that Fedora doesn't like debug output from Qt (admittedly, their libs seem to output quite a bit more, so that there was quite a bit more than the mere molsketch output), see this bugreport and luckily, (stackoverflow)[https://stackoverflow.com/questions/36338000/qml-console-log-and-console-debug-dont-write-to-console] knows how to fix it (which led me to the bug report in the first place).

Cheers,
Hendrik

[Alexander Ploumistos]

As for the debugging, it seems that Fedora doesn't like debug output from Qt (admittedly, their libs seem to output quite a bit more, so that there was quite a bit more than the mere molsketch output), see this bugreport and luckily, stackoverflow knows how to fix it (which led me to the bug report in the first place).

A few years ago, some people complained on the devel mailing list about the volume of messages that was displayed in the terminal when users launched programs. Though I don't remeber that discussion resulting in a distro-wide policy, the general sentiment was that debugging strings and warnings should not be exposed to the user unless explicitly requested. I suppose some developers and packagers decided to move stuff in that direction.

[Hendrik Vennekate]

Oh well, I just pushed the fix (latest snapshot, as usual). Not terribly well tested, but it should at least solve this particular problem. Input validation for OpenBabel definitely seems to be something to look at in the future...

Best,

Hendrik

[Alexander Ploumistos]

I've just started a local build, as soon as that completes and I run some tests, I will submit molsketch-0.5.0-5 to copr.

I noticed that you added the xpm icon back and I updated the %files section accordingly.

Aboslutely unimportant, I saw some "INCHI_FOMRAT" declarations in obabeliface.cpp, which I guess should be "INCHI_FORMAT". Of no consequence, since it's consistent across the file, but I thought I should mention it.

[Hendrik Vennekate]

Ah, thanks, I should really "spell-cheek" that better (unfortunately, as far as I know, Qt Creator -- unlike, e.g. Eclipse, does not provide that, or does it?).

[Hendrik Vennekate]

Hi Alexander,

I'm guessing we can close this now, can't we?

Best,

Hendrik

[Alexander Ploumistos]

Hi Hendrik,

Of course. I would have closed it myself, but sf doesn't allow the reporter to close bugs.