> How do I convert the following information in the > messages log to a line number in the source code? > > > BAD TRAP: type=e (#pf Page fault) > rp=ffffff0008d0d610 addr=50 occurred in module > "module" due to a NULL pointer dereference > > . > > . > > . > > Dec 11 14:27:31 machine genunix: [ID 655072 > kern.notice] ffffff0008d0d800 module:method+792 () > > In other words, how can I convert the 792 to a source > code line number? I know its in the method of module, > but the 792 (assembler line number) doesn't help me. >
That's almost certainly not a line number, but an offset, i.e. from the nearest earlier symbol to the PC location at the point the trap was taken. AFAIK, the kernel doesn't deal in debugging info to the level of line numbers (even if one compiled with -g to make it available, assuming that's ok for a kernel module, which I don't know). Nor do I know enough about ELF to determine offset to line number correspondence even if it _was_ compiled with -g, in a situation where no debugger is likely to be of much help. (which is to say, I don't know what the section name or whatever of the line number table is, nor how to interpret it) (And btw, changing things to make the kernel report line numbers would likely suck up an _insane_ amount of memory that could normally be used for much better purposes, even if it were otherwise feasible (which I wouldn't even want to hazard a guess at) and not a huge amount of work that could normally be better applied to other purposes. So I doubt there's any point in going there.) Maybe someone with a lot of practice at kernel debugging could offer some suggestions as to how you might narrow down a little, although you'd likely have to provide more info for them to be of more specific help. I gather from the format of the BAD TRAP message that you're on x86, but that (and finding what I think is the code that prints the offset in the traceback routines) is about as far as I got. I suppose a lot of people traditionally would have just sprinked ASSERT() around liberally (such as wherever you had a pointer that shouldn't have been NULL). That way, you'd get your panic from the failed assertion rather than from a trap, which should provide a line number (supplied by the macro at compile time). This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
