Thu 05 Jan 2017 09:40:33 PM UTC, original submission:
Put out of #49987 as a possibly separate bug.
Not sure if the reason is in database package or Octave.
Similar with Octave-4.3.0+ (2017-01-03, 53bb781d70c0) and Octave-4.0.0.
If the common oct-file of 'database', pq_interface.oct, is loaded into Octave (due to a 'which _pq_connect_' command), Octave segfaults. In Octave-4.3.0+, the backtrace is at least several thousand frames long, seemingly due to recursion. In Octave-4.0.0, the backtrace is readable (attached). It shows some stuff seemingly related to dlopen, opening the correct file .../pq_interface.oct, and immediately afterwards routines of core Octave, in graphics.cc/h, not of 'database'. So I thought the backtrace was corrupted and tried something different: I introduced dummy global variable initializations, with test outputs to stdout, to the beginning and end of each compilation unit (cc-file). Compiled with optimization switched off (-O0). I got the segfault again, but no test outputs at all! (Yes, page_screen_output was 'false', and there were the usual outputs with 'panic ...'.) So it seems that there were no initializations of globals done at all. But the only package code run at dlopen time should be for initialization of globals, or am I wrong? What then can have caused the segfault? Something in core Octave? But other packages worked ... Has anyone a clue?
|