bugGNU Octave - Bugs: bug #45346, octave crashes when trying to...

 
 

bug #45346: octave crashes when trying to install database package

Submitted by:  None
Submitted on:  Thu 18 Jun 2015 09:15:15 AM UTC  
 
Category: Octave Forge PackageSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Segfault, Bus Error, etc.
Status: InvalidAssigned to: None
Originator Name: robert.chavanne@laposte.netOriginator Email: -unavailable-
Open/Closed: ClosedRelease: 4.0.0
Operating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 23 Jun 2015 08:11:40 AM UTC, comment #11:

Ok, nice.

So can someone please close this bug, marking it 'invalid' or so?

Olaf Till <i7tiol>
Project Member
Tue 23 Jun 2015 07:41:19 AM UTC, comment #10:

I uninstalled the old package. And it works.
Thanks a lot for your support.

Robert CHAVANNE <rchavann>
Mon 22 Jun 2015 04:19:00 PM UTC, comment #9:

Wandering why your 2nd backtrace also shows no debugging information for liboctinterp.so.2 I realized that it's the wrong library. Sorry, had I seen this before it probably would have spared you the work ... While your Octave is loaded from a local installation:

Starting program: /usr/local/bin/octave --no-gui-libs

The used liboctinterp is from a system directory:

#8 0x00007fffdef9056b in ?? () from /usr/lib/x86_64-linux-gnu/liboctinterp.so.2

, probably a leftover of a previous Octave installation from a Debian package. This does not only hinder debugging, it may be even the cause of the observed crash (although I wander how it happens that Octave can load the wrong library).

What you can do to test your new Octave without the interfering old library:

If you don't need the Octave from the Deb package, deinstall the Deb package and check that /usr/lib/x86_64-linux-gnu/liboctinterp.so.2 is indeed not present anymore. It may be possible then to use your compiled Octave without recompilation.

If you still need the old Octave, try (without recompilation)

export LD_LIBRARY_PATH="/usr/local/lib"

/usr/local/bin/octave

If this does not help, you could

export LD_RUN_PATH="/usr/local/lib"

(and possibly also: export LD_LIBRARY_PATH="/usr/local/lib")

before

make clean; ./configure; make

of your new Octave.

Olaf Till <i7tiol>
Project Member
Mon 22 Jun 2015 01:00:23 PM UTC, comment #8:

I have added a more complete version of the backtrace after having compiled with -g and -O0 options.

(file #34291)

Robert CHAVANNE <rchavann>
Mon 22 Jun 2015 08:13:45 AM UTC, comment #7:

I will give it a try ASAP. Many thanks for your help.

Anonymous
Sat 20 Jun 2015 09:19:55 PM UTC, comment #6:

Still stuck. The crash seems to happen when ldopen initializes globals. I found no globals in 'database' which could directly cause a constructor call in liboctinterp.so.2 with a stack as it follows upwards from liboctinterp.so.2 in the backtrace. I also didn't find how Octave could introduce such globals into pq_interface.oct.

Unfortunately, liboctinterp.so.2 doesn't seem to contain file- and line-information for debugging (although liboctave seems to contain it). If we could see this information, this could give a clue.

Could you try to recompile Octave and make a new backtrace? You probably would have to call 'make clean' before recompiling. Then e.g.

export CXXFLAGS='-g'

and then ./configure and make.

Still better is

export CXXFLAGS='-g -O0'

but this slows Octave down and you will have to recompile later without -O0 for your own work.

Olaf Till <i7tiol>
Project Member
Thu 18 Jun 2015 10:52:48 PM UTC, comment #5:

I agree with Olaf's comment, there's nothing strongly indicating that this is specific to the database package, as the crash happens after all the oct-files have been compiled and linked, but possibly when they are being loaded by pkg for generating the doc-cache file.

Mike Miller <mtmiller>
Project Administrator
Thu 18 Jun 2015 04:22:29 PM UTC, comment #4:

Ok, that backtrace is more information. Sorry for having been sarcastic before.

I forgot that the lookfor cache is created already at install time (allthough we just recently had a problem due to this code in pkg ...). I'd say the problem can only occur in non-root installs (but even so I can't reproduce it ...).

But I'll have some problems with the backtrace. In the past there was a problem due to undefined order of initialization, but I can't see something pointing to any constructors of 'parallel' in the backtrace. The segfault occurs after dlopen, after going through a stack of Octaves internal functions. It's difficult to find out a relation to something in the loaded shared binary (pq_interface.oct). Although it looks suspicious that an Octave function _dl_catch_error is called; but that probably should not lead to a segfault.

I'll need some time for this, and success is doubtful since I can't reproduce the issue. It may turn out that the problem is in Octave; maybe an insider has a clue, sparing me some digging.

Olaf Till <i7tiol>
Project Member
Thu 18 Jun 2015 02:21:03 PM UTC, comment #3:

Please provide a full log of the output when installing with

If Octave really is crashing, it would help to see a gdb backtrace of Octave when the crash occurs, run the following steps (prompts shown to differentiate between bash, gdb, and octave prompts):

Mike Miller <mtmiller>
Project Administrator
Thu 18 Jun 2015 11:26:17 AM UTC, comment #2:

Thank you for the detailed information.

I can't reproduce this, and AFAICS it can't have anything to do with code in the database package, since 'pkg install' does not load the package, so not even its PKG_ADD instructions are executed.

Olaf Till <i7tiol>
Project Member
Thu 18 Jun 2015 10:59:59 AM UTC, comment #1:

adding maintainer of the database package to the cc list

Carnë Draug <carandraug>
Project Member
Thu 18 Jun 2015 09:15:15 AM UTC, original submission:

Hello, typing 'pkg install -forge database' at prompt makes octave crash.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #34291:  gdb_debug45346.txt added by rchavann (39KiB - text/plain - A new version of the backtrace after changing Octave's compilation options.)
file #34256:  gdb_bug45346.txt added by None (32KiB - text/plain - In the attached file you will find all the outputs seen when using gdb. Especially the backtrace lies at the end. Hope it can help.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rchavann (Updated the item)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by i7tiol (Posted a comment)
  • -unavailable- added by carandraug (Olaf Till - maintainer of database package)
  • -unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 23 Jun 2015 02:03:28 PM UTCcarandraugStatusNeed Info=>Invalid
      Open/ClosedOpen=>Closed
    Mon 22 Jun 2015 01:00:23 PM UTCrchavannAttached File-=>Added gdb_debug45346.txt, #34291
    Thu 18 Jun 2015 02:31:29 PM UTCNoneAttached File-=>Added gdb_bug45346.txt, #34256
    Thu 18 Jun 2015 02:21:03 PM UTCmtmillerStatusNone=>Need Info
    Thu 18 Jun 2015 10:59:16 AM UTCcarandraugCarbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup1