[Bug guile/17923] New: scheme exception about invalid object in a backtrace

[Bug guile/17923] New: scheme exception about invalid object in a backtrace

[mdaniels at lanl dot gov]

https://sourceware.org/bugzilla/show_bug.cgi?id=17923

            Bug ID: 17923
           Summary: scheme exception about invalid object in a backtrace
           Product: gdb
           Version: 7.8
            Status: NEW
          Severity: normal
          Priority: P2
         Component: guile
          Assignee: unassigned at sourceware dot org
          Reporter: mdaniels at lanl dot gov

I'm using the GDB/Guile interface and I find that gdbscm_frame_valid_p
throws exceptions about the frame object being invalid in the inferior.

It is the initial call to frscm_get_frame_smob_arg_unsafe throws a
scheme exception, not the one in the GDB try/catch.  

I've found a workaround is write instead:

  if (!(f_smob->inferior == NULL)) {

  }

I wasn't using the frame-valid? call until I start to have calls like
frame-name or frame-older fail in a similar way.  It happens a few
minutes into a run.  

I don't really understand why the inferior would go away to begin with.
This is in a breakpoint handler that is selectively taking info from
different frames.

Or could it be garbage collector related?  (Given that it is a Scheme
exception.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug guile/17923] scheme exception about invalid object in a backtrace

[xdje42 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17923

Doug Evans <xdje42 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xdje42 at gmail dot com

--- Comment #1 from Doug Evans <xdje42 at gmail dot com> ---
Hi.
Is it possible to provide a repro?
It would be good to verify what is causing the problem.
[IOW, how is f_smob->inferior becoming NULL?]

On a related note,
It's debatable whether this predicate should throw an exception if either the
inferior goes away or if the inferior exits.
Returning #f would still be reasonable in those circumstances.
The code is the way it is currently because that's how the python version
works.
[That's not the problem here. Just thinking out loud about a related issue.]

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug guile/17923] scheme exception about invalid object in a backtrace

[mdaniels at lanl dot gov]

https://sourceware.org/bugzilla/show_bug.cgi?id=17923

--- Comment #2 from Marcus Daniels <mdaniels at lanl dot gov> ---
"It would be good to verify what is causing the problem.
[IOW, how is f_smob->inferior becoming NULL?]"

Unfortunately, it is only happening on a secure network with a secure code and
so it would be illegal for me to disclose any more details.  I perhaps could
find some other code with other breakpoints that acts this way.

One clarification is that the inferior is not really crashing or exiting.  It
is a periodic thing that during a run that some of the frequent breakpoints
have this property where the exception in frame-valid? occurs (obviously it
would happen in the other frame-* functions too if the precaution of modified
frame-valid? is not used).   Suppressing it in the way I said means I can't get
parent frame info, but come the next breakpoint (or the next 100), the frame-*
functions seem to work fine.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug guile/17923] scheme exception about invalid object in a backtrace

[mdaniels at lanl dot gov]

https://sourceware.org/bugzilla/show_bug.cgi?id=17923

--- Comment #3 from Marcus Daniels <mdaniels at lanl dot gov> ---
Here's another error I witnessed:

./guile/scm-gsmob.c:268: internal-error: gdbscm_clear_eqable_gsmob_ptr_slot:
Assertion `slot != NULL` failed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug guile/17923] scheme exception about invalid object in a backtrace

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17923

dje at google dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at google dot com

--- Comment #4 from dje at google dot com ---
(In reply to Marcus Daniels from comment #3)
> Here's another error I witnessed:
> 
> ./guile/scm-gsmob.c:268: internal-error: gdbscm_clear_eqable_gsmob_ptr_slot:
> Assertion `slot != NULL` failed.

Is it possible to provide a repro for this?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug guile/17923] scheme exception about invalid object in a backtrace

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17923

--- Comment #5 from dje at google dot com ---
(In reply to dje from comment #4)
> (In reply to Marcus Daniels from comment #3)
> > Here's another error I witnessed:
> > 
> > ./guile/scm-gsmob.c:268: internal-error: gdbscm_clear_eqable_gsmob_ptr_slot:
> > Assertion `slot != NULL` failed.
> 
> Is it possible to provide a repro for this?

OTOH, if a repro is impossible maybe you could help debug this?
[since you're hacking the code already]

E.g., for the frame problem, is it possible to set a breakpoint on one of the
frame functions early on, when f_smob->inferior is not NULL, set a watchpoint
on it, and then continue?  When the watchpoint triggers a backtrace may be
sufficient to isolate the culprit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug guile/17923] scheme exception about invalid object in a backtrace

[mdaniels at lanl dot gov]

https://sourceware.org/bugzilla/show_bug.cgi?id=17923

--- Comment #6 from Marcus Daniels <mdaniels at lanl dot gov> ---
"for the frame problem, is it possible to set a breakpoint on one of the frame
functions early on, when f_smob->inferior is not NULL, set a watchpoint on it,
and then continue?  When the watchpoint triggers a backtrace may be sufficient
to isolate the culprit."

Could you clarify if there is ever a situation in which f_smob->inferior ought
to become NULL, even if the debugged program is continuing?

For now I'm trying to add guards to frame-* calls using the modified
frame-valid to see what other problems I run into.  If it is an endless chain
of problems, I can't afford to keep debugging and need to take another
approach.  If it is a bounded set, then perhaps I can afford to debug these
issues.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug guile/17923] scheme exception about invalid object in a backtrace

[xdje42 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17923

--- Comment #7 from Doug Evans <xdje42 at gmail dot com> ---
(In reply to Marcus Daniels from comment #6)
> "for the frame problem, is it possible to set a breakpoint on one of the
> frame functions early on, when f_smob->inferior is not NULL, set a
> watchpoint on it, and then continue?  When the watchpoint triggers a
> backtrace may be sufficient to isolate the culprit."
> 
> Could you clarify if there is ever a situation in which f_smob->inferior
> ought to become NULL, even if the debugged program is continuing?

There are only two situations where f_smob->inferior changes from non-NULL to
NULL:
1) when the inferior goes away,
2) when the frame's Scheme object is garbage collected.

> For now I'm trying to add guards to frame-* calls using the modified
> frame-valid to see what other problems I run into.  If it is an endless
> chain of problems, I can't afford to keep debugging and need to take another
> approach.  If it is a bounded set, then perhaps I can afford to debug these
> issues.

All I'm asking for is to run gdb under gdb with a watchpoint set to catch the
changing of f_smob->inferior from non-NULL to NULL and then sending me a
backtrace. I'm hoping this will be doable.
If you need instructions please let me know.
Basically, run gdb under gdb, and set a breakpoint at the end of
frscm_scm_from_frame *after* this line:

  f_smob->inferior = inferior;

Then in the parent gdb do "watch -l f_smob->inferior",
and then "continue" the child gdb and continue the session
doing whatever tickles this bug.
When the bug is tickled (presumably) the watchpoint will fire
and you will be in the parent gdb.  Then do "backtrace".

Thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.