bugGNU Octave - Bugs: bug #37343, Debian 3.6.2-5 unreproducible...

 
 

bug #37343: Debian 3.6.2-5 unreproducible crashes

Submitted by:  Francesco Potortì <pot>
Submitted on:  Thu 13 Sep 2012 12:58:56 PM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Crash
Status: Works For MeAssigned to: None
Originator Name: Open/Closed: Closed
Release: 3.6.2Operating System: GNU/Linux

Add a New Comment (Rich MarkupRich 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)

Thu 20 Sep 2012 09:39:05 PM UTC, comment #11:

We need a better diagnostic than "random crashes". Also, the current dev version has diverged so much from Debian that it's unlikely the crashes are related.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 20 Sep 2012 08:41:47 PM UTC, comment #10:

I am seeing random crashes also.

6823ad7a25b1 tip

Doug Stewart <dastew>
Thu 20 Sep 2012 03:28:39 PM UTC, comment #9:

An unreproducible bug is a bug that doesn't exist. Until I can at least make valgrind complain, I cannot find the source of trouble.

I'm tempted to rename this bug to problems with warning, since it's the only useful information so far.

We need to write some good debugging docs. Here is a start:

http://wiki.octave.org/Debugging_Octave

I don't think it will be particularly useful to attempt to debug the Debian binaries, since they are optimised builds and debugging an optimised build is not as informative.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 20 Sep 2012 03:20:16 PM UTC, comment #8:

Regarding the crash, I cannot reproduce the bug at will, as I said. It comes when it likes :)

Regarding outputting a struct, I can only guess that it is expected, yet undocumented, behaviour.

Regarding reading it back, I have no idea (Matlab compatibility?)

Regarding debugging, if someone pointed me to relevant docs, I would like to routinely run Octave under gdb, only I do not know how, even after having installed Debian's octave-gdb package.

Francesco Potortì <pot>
Thu 20 Sep 2012 03:06:14 PM UTC, comment #7:

Even after uncommenting the warning lines, I cannot trigger any nasal demons, although I do see other trouble with warnings that seem surprising to me. Why is it outputting a struct, and why isn't this struct being read back into the warning function?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 20 Sep 2012 11:47:33 AM UTC, comment #6:

No answer to my preious request?

I installed Debian's octave-bug package, but I do not know how to use it.

Francesco Potortì <pot>
Thu 13 Sep 2012 04:28:05 PM UTC, comment #5:

Oh, sorry, I realise that misinterpreted your request. And sorry again because I meant to restore the bug before attaching and I forgot...

To restore the bug, just uncomment the two instances where the warning() function is called.

Francesco Potortì <pot>
Thu 13 Sep 2012 04:20:46 PM UTC, comment #4:

2. That doesn't happen on my machine.

The problem is that it does not happen on my machine either: as I said, I can't reproduce it. It happened in seemingly unrelated ways four or five times during a whole day of working heavily on Octave, but each time I tried to do "do it again" nothing happened. Even if I had the time to try, I could not reproduce the steps from the start of Octave session to the crash, because the code that I was developing had changed many times during the session.

Anyway, I have installed Debian's octave-dbg package. I expected it to replace the octave package with a bulkier executable containing the symbol table so that when I run it under gdb I could get a backtrace, but this was not the case. I should assume that I am behind the times with debugging technology.

What should I do to get a backtrace in case it crashes on me again?

Francesco Potortì <pot>
Thu 13 Sep 2012 04:03:19 PM UTC, comment #3:

> I knmow this is little info, but who knows? It may trigger something
> in the developers' brains. At least knowing that this happens is
> better than not knowing...


Oh, we get nasal demon reports all the time. A generic nasal demon is
not enough to know what could possibly be wrong... :-)

> I attach the program I was running, but I fear this will change
> little. There is a bug in the program. After I corrected it, Octave
> did not crash any more, but I was near the end of development then,
> so I fear there is no correlation.


So, with your attached code, this brings us to the 2nd stage of
debugging:

http://bash.org/?950581

Can you restore the bug in your code so we can see the bug in Octave?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 13 Sep 2012 02:03:11 PM UTC, comment #2:

I knmow this is little info, but who knows? It may trigger something in the developers' brains. At least knowing that this happens is better than not knowing...

As I wrote, it did already happen several times, "in unreproducible ways", as all good memory corruption bugs do.

Anyway, I'll install Debian debugging version and try to run it under gdb.

I attach the program I was running, but I fear this will change little. There is a bug in the program. After I corrected it, Octave did not crash any more, but I was near the end of development then, so I fear there is no correlation.

The bug is how I use the variable 'oldw', which I treat like a string while it is a struct (undocumented, should write a patch for this).

Oh, now that I remember, this uses broadcasting. Since this is new to Octave, and Octave had very rarely crashed on me before, I'd suspect the broadcasting code.

(file #26548)

Francesco Potortì <pot>
Thu 13 Sep 2012 01:33:09 PM UTC, comment #1:

As you well know, this is impossible to debug with the information you've given. If by your own description this is unreproducible, then it doesn't happen again. So, an invisible bugs that only happened once and can't be made to happen again? There has to be a better description of the problem than this. :-/

At the very least, tell us what program you were running and how. Also, try to get some valgrind output or a stack trace from gdb. Do you need instructions on how to do that?

More humourously, http://i.imgur.com/jacoj.jpg

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Thu 13 Sep 2012 12:58:56 PM UTC, original submission:

During a session of tests, loading functions and so on I got sevceral crashes in apparently unreproducible ways. This is the message I got during the last one:

octave> clear all
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete

Process ctav segmentation fault (core dumped)

I lost the messages from the previous ones. In one of them, a backtrace was printed which showed a problem in the libc, which said something about freeing unallocated memory, if memory serves me well. I can try to give more detail should that happne again.

Francesco Potortì <pot>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #26548:  bug.m added by pot (9kB - text/x-objcsrc)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Updated the item)
  • -unavailable- added by dastew (Posted a comment)
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by pot (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 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 23 Jun 2013 11:56:49 PM UTCrik5Open/ClosedOpen=>Closed
    Thu 20 Sep 2012 03:28:39 PM UTCjordighStatusNeed Info=>Works For Me
    Thu 13 Sep 2012 02:03:11 PM UTCpotAttached File-=>Added bug.m, #26548
    Thu 13 Sep 2012 01:33:09 PM UTCjordighStatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup