Re: Program hangs at _dl_sysinfo_int80, what does it mean?

From: Paul Pluzhnikov (ppluzhnikov-nsp_at_charter.net)
Date: 03/01/05


Date: 28 Feb 2005 19:52:00 -0800


"LaBird" <wlcheung1975@hkucs.org> writes:

> I just found another symptom, that happens occasionally, is that one
> of my global variables which checks the number of incoming messages
> suddenly loses count somewhere in my program. Usually it goes alright
> from 0, 1, 2, ..., incrementing once when each message fulfilling a
> certain condition arrives. But I found during the execution, it suddenly
> resets back to 0 (but I didn't reset it anywhere in my code), even I
> declare that variable as volatile. Why would this happen?

The most likely cause is a bug in your program.
Unfortunately, locating such bugs is often quite hard.

> Is it true that
> the program already gets to a "bad state" so that any unexpected
> behavior like this can happen?

Not any -- some code still must store the 0 to the address of your
corrupted global. If this global is updated infrequently, a gdb
watch point may help you find the culprit.

> Or, is it a suggestion that I have
> used too much resource? (e.g. Too many levels of nested signals, as
> I allow SIGIO to be called within the signal handler while it serves the
> previous one, or, is using up too much virtual memory space a
> possible cause as well?)

None of the above are likely causes, I think.
A (global) buffer overflow or a "stray" pointer are much more likely.

Unfortunately valgrind is quite unlikely to find this bug (though
it may find many other bugs, so you should try it anyway :-)

You may also want to try Insure++ from Parasoft.

Cheers,

-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.


Relevant Pages

  • Re: slurping in binary data
    ... that I must figure out precisely why it is that I don't expect the bug ... However, the recursion always ... I recently investigated a bug where there were missing packets from the output files of one of my programs. ... Because those were the easiest things to check, they were also the first things I checked (despite direct orders from upper management that I was not supposed to "waste" any time investigating the "impossibility" that those input files were defective). ...
    (comp.lang.c)
  • Re: slurping in binary data
    ... that I must figure out precisely why it is that I don't expect the bug ... However, the recursion always ... there were missing packets from the output files of one of my programs. ... certain assumptions about the contents of the input files. ...
    (comp.lang.c)
  • Re: Python bug? Named parameters in recursive calls sometimes confuses python?
    ... > Isn't it possible that the code has just returned twice? ... down in the recursion, instead of reverting to the object ... a Python bug! ... (It's the pure Python version 0.8) ...
    (comp.lang.python)
  • Re: [PATCH] workqueue: not allow recursion run_workqueue
    ... works is not run orderly when recursion run_workqueue ... It's bug. ... So we should not allow workqueue trying to flush its own queue. ... struct workqueue_struct *wq; ...
    (Linux-Kernel)
  • Re: [PATCH 2/3] workqueue: not allow recursion run_workqueue
    ... works is not run orderly when recursion run_workqueue ... It's bug. ... So we should not allow workqueue trying to flush its own queue. ...
    (Linux-Kernel)