[Please note: I read this list via mail-index, which has been dropping a lot
 of mail it seems.  If you reply, PLEASE INCLUDE ME in the To: line.  Until
 the mail-index.netbsd.org problems are sorted out, replies to the list are
 very possibly going into the bit-bucket as far as I'm concerned.]

I wasn't sure if I should post to netbsd-help or tech-pkg.  Despite a spate
of cross-postings, I resisted the urge to cross-post, since those do
make life harder.  (^&  If I don't receive any replies, I'll re-post to
tech-pkg.


 The short of it:

Here's the situation:

I have started work on a program that uses a pkgsrc shared library.  At
a certain point, it crashes WITHIN the shared library.  Of course, the
shared library in question is widely used, and I myself have used it in
similar ways in other programs.  On the other hand, the library *is*
crashing if and only if I give it a certain X11 event from the mouse.  The
library has it's own X event loop; if I give it any other event, it works.
All that I can see via gdb are raw disassembly and function names.

I'd really like to see what's going on when it's running.  (^&



 The long of it:

Concrete details: I'm using the GLUT.  The event is when I scroll the
mousewheel down (or was that up? one way is fine, the other crashes).
The GLUT seems to corrupt its stack while reading X events.

I *have* used the scroll-wheel in GLUT programs (even of my own writing)
on this very same machine, with the same GLUT, etc.

On the other hand, any *other* X input event is fine.  The crash happens
in GLUT's X input-processing loop.

It seems to scribble garbage over the stack in GLUT's
interruptibleNextEvent(), though I don't know why it's doing that.
I can watch it trace up to a certain point in the debugger, and then
it halts waiting on X.  If I do the ONE thing that it doesn't like,
life is bad and short.  Otherwise, the GLUT safely calls my callbacks
and everything looks great.

The program that's using the GLUT is a sketch of a GUI library
layered on top of the GLUT.  (The closest that I've found to
what I want is GLUI, but it's under the LGPL and I prefer my
"instantiate an object" over GLUI's "call a member function"
approach.  Not that I'm biased by the fact that the former
is my design, of course...)


I *tried* the "obvious" of adding "-ggdb" to the compiler command for
the GLUT's makefile (...pkgsrc/graphics/glut/work/Mesa*/Makefile) from
a clean "make patch", then after modifying the Makefile, "make" and
copy the resulting libraries over the /usr/lib/X11R6/lib/libglut*
files.  Naturally, I re-compiled the test program just to be sure
that the debugging info didn't move the symbols around.  That wasn't enough.

(After doing that copy, the program behaves exactly the same way,
and the debugger only sees raw machine code plus GLUT function names,
which is what I was getting before.)

I'd like to ask gdb about variables in the GLUT, and see the C source
lines.  Reading x86 assembly and trying to correlate to C is not fun.
Nor is it terribly productive...

So, what is needed in order to more usefully trace into a shared
library from pkgsrc using gdb?  Bear in min that I actually have
a tradition of preferring to stare at code and sometimes sprinkle
output statements, so I may just not be using gdb adequately.  (^&
Feel free to assume that I haven't done anything re. gdb or
compiling for gdb if I didn't say it above.



Thanks in advance for any assistance.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/