-
Notifications
You must be signed in to change notification settings - Fork 1
Known Issues
NOTE: this list is mainly intended only for issues with Molpher dependencies and technology ecosystem required for its development or operation. Any bugs or issues related to Molpher source code should be tracked by Trac tickets.
During testing, it was observed that certain antivirus products flag Molpher binaries as possible suspects because of their low occurrence and try to run them automatically in sandbox. In case the Molpher actually manages to start in the sandbox, its performance would be severely decreased and communication between frontend and backend would not work. Either way, user is advised to make an explicit exception in the antivirus whitelist to allow Molpher to run natively. During the initial development, one developer reported strange system-wide memory leak when testing Molpher backend launched from within !NetBeans. Even though the problem could not be reproduced on other machines, it was proven that memory exhaustion was not caused by Molpher binaries. In the end, it was tracked down to the Cygwin console which is used by !NetBeans instead of native Windows console. While it is not completely sure, the problem was probably caused by repeated killing of conhost process that can be seen in task manager when Cygwin console is running. While there are some references about this strange hack (supposedly introduced because of Windows 7 beta) on the Cygwin discussion boards, it is not clear whether it is still relevant nowadays. If any future developer of Molpher encounter similar problem, it can be circumvented either by switching console type in !NetBeans project configuration from External Console to Standard Output or by renaming/deleting all kill.exe files available through system Path variable. During the initial development, it proved to be challenging to implement Molpher algorithm on top of the RDKit library while keeping the entire solution robust enough to allow long running execution. The situation is caused by differing approach to handling of invalid molecules (i.e. molecules that can be structurally described but do not have chemical or physical meaning). While RDKit is implemented and designed with almost zero tolerance towards invalid molecules, the relaxed definition of chemical space used by Molpher algorithm allows generation of invalid molecules. In this sense, Molpher could be viewed as a fuzz tester of RDKit validation and sanitization routines (RDKit tries to repair invalid molecules before discarding). But because RDKit is mainly used by researchers and users who usually feed it with valid molecules, those routines are not thoroughly tested and might crash or go into infinite loop when handling molecules generated by Molpher. Another problem is that RDKit sanitization routines are overly strict and often discard molecule only because of ambiguous way of how to sanitize it.Originally, it was experimented with taking sanitization out of the game but with not much success. While it is possible to ask RDKit to partly or even entirely skip the sanitization step, it would be helpful only if such molecule never again returned as an input for morphing because there are RDKit functions that either refuse or that are not prepared to handle unsanitized molecules. By further experiments, certain critical subset of sanitization was established which together with some preprocessing on Molpher side (Kekulization, molecule copying and ion handling) lead to the reliable and robust implementation where a molecule is discarded only very rarely.
Keeping in mind all of the above, it should be clear that upgrade of RDKit library to the newer version is potentially dangerous. As of writing this, Molpher is using RDKit 2011.12. It was tried to upgrade RDKit to 2012.03 but it contains bug in ring detection causing infinite loop when handling certain molecules produced by Molpher. Still, it is highly recommended to try to upgrade RDKit in future because there might be significant performance improvements in SMILES, fingerprint or similarity coefficient calculations, all of which are critical for Molpher performance. Before trying the upgrade, see release notes at https://sourceforge.net/mailarchive/forum.php?forum_name=rdkit-announce whether it is worth the trouble. Note that Molpher need to be thoroughly tested after the upgrade to ensure that there are no infinite loops and that the number of discarded morphs is still reasonably small.
NetBeans C++ parser tends to go into infinite loop when analyzing IDL macros from RCF (`RCF_METHOD_*`). To prevent that from happening, refer to trunk/common/netbeans_hack.h. There is a bug (QTBUG-22829) in Qt Meta Object Compiler that prevents it to process certain macros in Boost headers. Bug is being tracked by Qt developers, but it is not sure when it will be fixed. As a temporary solution, refer to trunk/frontend/qtmoc_hack.h.