octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #49992] database package segfaults at dlopen t


From: Olaf Till
Subject: [Octave-bug-tracker] [bug #49992] database package segfaults at dlopen time
Date: Thu, 5 Jan 2017 21:40:34 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0

URL:
  <http://savannah.gnu.org/bugs/?49992>

                 Summary: database package segfaults at dlopen time
                 Project: GNU Octave
            Submitted by: i7tiol
            Submitted on: Thu 05 Jan 2017 09:40:33 PM GMT
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Crash
                  Status: None
             Assigned to: None
         Originator Name: Olaf Till
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: other
        Operating System: GNU/Linux

    _______________________________________________________

Details:

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?



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Thu 05 Jan 2017 09:40:33 PM GMT  Name: database-backtrace  Size: 15kB  
By: i7tiol

<http://savannah.gnu.org/bugs/download.php?file_id=39382>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?49992>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]