"user config" button crashes

[ceheitsch]

math11024:~ heitsch$ /usr/local/opt/rnastructviz/bin/RNAStructViz ️ ERROR: Handling unexpected SEGFAULT (SIGSEGV) signal.

.########..##....##....###.....######..########.########..##.....##..######..########.##.....##.####.######## .##.....##.###...##...##.##...##....##....##....##.....##.##.....##.##....##....##....##.....##..##.......##. .##.....##.####..##..##...##..##..........##....##.....##.##.....##.##..........##....##.....##..##......##.. .########..##.##.##.##.....##..######.....##....########..##.....##.##..........##....##.....##..##.....##... .##...##...##..####.#########.......##....##....##...##...##.....##.##..........##.....##...##...##....##.... .##....##..##...###.##.....##.##....##....##....##....##..##.....##.##....##....##......##.##....##...##..... .##.....##.##....##.##.....##..######.....##....##.....##..#######...######.....##.......###....####.########

==== 🧬 RNAStructViz v1.9.6-testing -- RNA Secondary Structure Comparison Multi-Tool ====

ABOUT THIS APPLICATION:

Git Revision .............................. [Wed Nov 20 11:36:27 2019] Revision Date ............................. Darwin (18.7.0) [x86_64] @@ math11024 FLTK Library .............................. 1.4.0 (API #10400) FLTK-Config ............................... Cairo Library ............................. 1.16.0 Target Platform ........................... /usr/local/Cellar/fltkwithcairo/fltk-1.4.x-20191115-ee9ada96_4/bin/fltk-config Local Build Time .......................... RNAStructViz Launch Path Command .......... /usr/local/opt/rnastructviz/bin/RNAStructViz Current Working Directory (CWD) ........... /Users/heitsch Active System User (From ENV) ............. heitsch

============================================================================================

BUG REPORT INFORMATION: Please include a screenshot along with this information in any bug report you submit. New issues with the application can be submitted by following the instructions at « https://github.com/gtDMMB/RNAStructViz/wiki/BugReportingAndErrors »

[maxieds]

Also able to reproduce and fix this buggy behavior on Linux. I believe it was caused due to floating calls to Fl_Window::make_current(), which means that it wouldn't have been present every time the button was clicked. Expect that the Mac behavior should now fall into line.

[ceheitsch]

@maxieds Please verify your expectation for Mac behavior by testing it under OSX. At that point, I will review and hopefully close.

[maxieds]

@ceheitsch Tested on Mac OSX. Verified new code is working. Please upgrade to a release of RNAStructViz >= v1.9.8-testing, test for yourself, and then close out the issue thread. Thanks.

[ceheitsch]

User config button still crashes in v2.0.1-testing under OSX 10.4.6. Copying command line information below.

================================================================= ==58300==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6040004aed3e at pc 0x0001087598e5 bp 0x7ffee8242c60 sp 0x7ffee82423f8 WRITE of size 45 at 0x6040004aed3e thread T0

0 0x1087598e4 in wrap_strncpy (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x568e4)

#1 0x107a045c0 in DisplayConfigWindow::TrimFilePathDisplay(char const*, int) (RNAStructViz:x86_64+0x1000485c0)
#2 0x107a0507a in DisplayConfigWindow::ConstructWindow() (RNAStructViz:x86_64+0x10004907a)
#3 0x107a047e7 in DisplayConfigWindow::DisplayConfigWindow() (RNAStructViz:x86_64+0x1000487e7)
#4 0x107a3c83e in MainWindow::ConfigOptionsCallback(Fl_Widget*, void*) (RNAStructViz:x86_64+0x10008083e)
#5 0x107ade96a in Fl_Widget::do_callback(Fl_Widget*, void*) (RNAStructViz:x86_64+0x10012296a)
#6 0x107ab0453 in Fl_Button::handle(int) (RNAStructViz:x86_64+0x1000f4453)
#7 0x107aaaf0d in send_event(int, Fl_Widget*, Fl_Window*) (RNAStructViz:x86_64+0x1000eef0d)
#8 0x107aaa952 in Fl::handle_(int, Fl_Window*) (RNAStructViz:x86_64+0x1000ee952)
#9 0x107a9e4ca in cocoaMouseHandler(NSEvent*) (RNAStructViz:x86_64+0x1000e24ca)
#10 0x7fff3d2fa019 in -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] (AppKit:x86_64+0x186019)
#11 0x7fff3d2f9666 in -[NSWindow(NSEventRouting) sendEvent:] (AppKit:x86_64+0x185666)
#12 0x7fff3d198e4a in -[NSApplication(NSEvent) sendEvent:] (AppKit:x86_64+0x24e4a)
#13 0x107a9bb94 in Fl_Cocoa_Screen_Driver::wait(double) (RNAStructViz:x86_64+0x1000dfb94)
#14 0x107aaa083 in Fl::wait() (RNAStructViz:x86_64+0x1000ee083)
#15 0x107a3648c in main (RNAStructViz:x86_64+0x10007a48c)
#16 0x7fff6bafa3d4 in start (libdyld.dylib:x86_64+0x163d4)

0x6040004aed3e is located 0 bytes to the right of 46-byte region [0x6040004aed10,0x6040004aed3e) allocated by thread T0 here:

0 0x10875f053 in wrap_malloc (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x5c053)

#1 0x107a0452a in DisplayConfigWindow::TrimFilePathDisplay(char const*, int) (RNAStructViz:x86_64+0x10004852a)
#2 0x107a0507a in DisplayConfigWindow::ConstructWindow() (RNAStructViz:x86_64+0x10004907a)
#3 0x107a047e7 in DisplayConfigWindow::DisplayConfigWindow() (RNAStructViz:x86_64+0x1000487e7)
#4 0x107a3c83e in MainWindow::ConfigOptionsCallback(Fl_Widget*, void*) (RNAStructViz:x86_64+0x10008083e)
#5 0x107ade96a in Fl_Widget::do_callback(Fl_Widget*, void*) (RNAStructViz:x86_64+0x10012296a)
#6 0x107ab0453 in Fl_Button::handle(int) (RNAStructViz:x86_64+0x1000f4453)
#7 0x107aaaf0d in send_event(int, Fl_Widget*, Fl_Window*) (RNAStructViz:x86_64+0x1000eef0d)
#8 0x107aaa952 in Fl::handle_(int, Fl_Window*) (RNAStructViz:x86_64+0x1000ee952)
#9 0x107a9e4ca in cocoaMouseHandler(NSEvent*) (RNAStructViz:x86_64+0x1000e24ca)
#10 0x7fff3d2fa019 in -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] (AppKit:x86_64+0x186019)
#11 0x7fff3d2f9666 in -[NSWindow(NSEventRouting) sendEvent:] (AppKit:x86_64+0x185666)
#12 0x7fff3d198e4a in -[NSApplication(NSEvent) sendEvent:] (AppKit:x86_64+0x24e4a)
#13 0x107a9bb94 in Fl_Cocoa_Screen_Driver::wait(double) (RNAStructViz:x86_64+0x1000dfb94)
#14 0x107aaa083 in Fl::wait() (RNAStructViz:x86_64+0x1000ee083)
#15 0x107a3648c in main (RNAStructViz:x86_64+0x10007a48c)
#16 0x7fff6bafa3d4 in start (libdyld.dylib:x86_64+0x163d4)

SUMMARY: AddressSanitizer: heap-buffer-overflow (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x568e4) in wrap_strncpy Shadow bytes around the buggy address: 0x1c0800095d50: fa fa fd fd fd fd fd fd fa fa fd fd fd fd fd fd 0x1c0800095d60: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fd 0x1c0800095d70: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa 0x1c0800095d80: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa 0x1c0800095d90: fa fa fd fd fd fd fd fa fa fa 00 00 00 00 00 00 =>0x1c0800095da0: fa fa 00 00 00 00 00[06]fa fa fa fa fa fa fa fa 0x1c0800095db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c0800095dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c0800095dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c0800095de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c0800095df0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==58300==ABORTING Abort trap: 6

[maxieds]

@cheitsch There were additional unforeseen bugs in the code that I noticed and fixed today working with a very short tRNA sequence case. Please upgrade to the latest v2.0.5-testing release and try again.

[maxieds]

@ceheitsch While you're at it, you should also check out how much nicer the improved StatsWindow plots look with the new integrated Vienna Boltzmann sampling features. This is to say, that RNAStructViz now supports loading vanilla FASTA files.

• Re-copy the sample structures directory to home using the first-run instructions;
• Load the default FASTA file case I added to the test set of stock files
• Open and view the resulting samples in the stats window ... Cool, right?

[maxieds]

For example, the following, and also the more varied ROC plots that result with more samples to compare to.

[maxieds]

@ceheitsch

By the way, you should be aware that the reason more crashes became immediately noticable starting in release v2.0.1-testing tagged earlier this morning, is that I intentionally started compiling in debugging utilities for memory violations by default. E.g., AddressSanitizer: heap-buffer-overflow, stack overflow protections, among others. This means, that when we encounter a mean nasty memory oversight in the code, there are custom memory access detection schemes going on over top of glibc's default functions to make it crash out right away. This means a few painful observations up front, but overall, more predictable behavior once these bugs are fixed properly. Without the extra debugging libraries it may (or may not, always) cause a crash in the short term.

This also means that if you are only noticing minor logic errors, as opposed to catastrophic consistent crashes that are repeatable, the code is pretty solid. There are still some memory leaks getting printed by the AddressSanitizer at the end of the application (on my TODO list), but most of the big crashes have been massaged out of the code over the past couple of days. Minor bugs not withstanding, we are basically ready at this point to find a way to get the recent release(s) out to a larger crowd of beta testers.

[ceheitsch]

@ceheitsch While you're at it, you should also check out how much nicer the improved StatsWindow plots look with the new integrated Vienna Boltzmann sampling features. This is to say, that RNAStructViz now supports loading vanilla FASTA files.

• Re-copy the sample structures directory to home using the first-run instructions;
• Load the default FASTA file case I added to the test set of stock files
• Open and view the resulting samples in the stats window ... Cool, right?

While this sounds interesting, it is way out of scope for the current program, and counter-productive to getting a stable enough version for beta testing. Please make a new branch(-es) with these changes in it, and revert master back.

[ceheitsch]

@ceheitsch

By the way, you should be aware that the reason more crashes became immediately noticable starting in release v2.0.1-testing tagged earlier this morning, is that I intentionally started compiling in debugging utilities for memory violations by default. E.g., AddressSanitizer: heap-buffer-overflow, stack overflow protections, among others. This means, that when we encounter a mean nasty memory oversight in the code, there are custom memory access detection schemes going on over top of glibc's default functions to make it crash out right away. This means a few painful observations up front, but overall, more predictable behavior once these bugs are fixed properly. Without the extra debugging libraries it may (or may not, always) cause a crash in the short term.

This also means that if you are only noticing minor logic errors, as opposed to catastrophic consistent crashes that are repeatable, the code is pretty solid. There are still some memory leaks getting printed by the AddressSanitizer at the end of the application (on my TODO list), but most of the big crashes have been massaged out of the code over the past couple of days. Minor bugs not withstanding, we are basically ready at this point to find a way to get the recent release(s) out to a larger crowd of beta testers.

Am perplexed by the description of "more crashes." I was hoping to close this issue, however the program still crashed when the "user config" button is clicked. It's great that the code is continuing to improve, but a basic feature (user configurability) is still not accessible.