This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 2 Segfaults in Insights (Latest CVS)


Steve,

We have a bug tracking database on the Insight web page
   http://sources.redhat.com/insight
You can use that to report bugs and make sure thay are not missed or forgotten
(well, this was not true before, but I will try to make sure now it is).
You still have to follow a few links for now (until we improve the page a bit).

W.r.t. your two problems here (which I have never seem before), lets talk about
the first as there is not much information about the second one yet.  here it goes:


Steven Johnson wrote:
> 
> When I choose download Insight almost immediately segfaults in "gdbtypes.c,
> line 1060" This is not the problem however, it is the symptom. A Stack trace
> gives me a trace through values.c, valops.c, eval.c and eventually to the
> function set_command in printcmd.c (line 1041).
> 
I would need to see this stack trace.  Can you post it please?


> This works fine if I start gdb with the --nw option BTW.
> 
This do point to a GUI problem or an interaction between the GUI and gdb.


> What I "think" the problem is:
> 
> Insight appears to hook all "set" operations when it is executing a gui command
> such as download. It does this, so that any variables that are changed by the
> command are updated on the display. My script adds a hook to the load
> operation. The hook writes to a register with:
> 
> set $ictrl=0x7
> 
Your are being too optimistic :-)  Insight is not that aware of things that are
done in the simulated console or even in the scripts (as they are still gdb scripts,
not insight scripts as we may have in the future).


> I need this because of peculiarities with the way I need to operate my
> hardware. Insight executes this command on the target properly. It then
> interprets the SET operation. Looks up symbol $ictrl (which doesn't exist, its
> a register not a symbol of the program.) tries to set it's local value to 0x7
> and segfaults because the pointer to the symbol is invalid crap. GDB without
> Insight doesn't do it because it does not post interpret the set operations.
> 
You are right that the problem has something to do with your set command, but the
GUI set command hook handlers do nothing of a sort.  I does grab data from the
command struct so it is possible that it could be fouled by some bad data in there.

But I would need to look at that stack and at the contents of the cmd_list_struct
that is passed back by gdb to the GUI in the hook callback.



> set_command is the culprit that does this. I have tested my hypothesis by
> commenting out the expression evaluation in set_command. When I do this,
> loading works fine. This is obviously not the correct fix. I can see what
> Insight is attempting to achieve and it is valid. Im not sure how to fix the
> case where the symbol doesn't exist. Any input would be appreciated as I would
> really like to get this fixed.
> 
> I think it could be forced on any Insight by creating a hook on load that
> updates a register to some arbitrary value. For example:
> 
> define hook-load
>   set $eax=0x01
>   set $eax=0x00
> end
> 
> I did it twice to defeat the register caching mechanism for the purposes of the
> test. (If the first write doesn't do anything, the second will.) I believe this
> will segfault Insight everytime (NOTE: I haven't tested this on an intel target
> myself)
> 

I will try that.  Thanks.



-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]