Debugging io-net modules is making my head hurt. I expect you can all
sympathise. My chief tool to date has been printf() in key places to
illustrate program flow. It seems the printf() calls are affecting timing
more than I expected though. If I switch to the console’s virtual screen the
filter crashes due to the time required to display the printf() to the
screen. If I sit on some other virtual screen everything works happily.
Then, when my filter crashes (for other reasons), I can switch over to the
console to get the post-mortem (the last screen-full of printf()). Now that
I’ve explained my current system of debugging, can anyone here give me
suggestions for a better method?
I also use gdb to analyze the core dump, but the information I need is
usually long lost by then. I can at least tell which module I crashed (below
me, or above me) but by then my module that caused the crash is well past
the actual problem point.
Cheers,
Shaun
Shaun Jackman <sjackman@nospam.vortek.com> wrote:
Debugging io-net modules is making my head hurt. I expect you can all
sympathise. My chief tool to date has been printf() in key places to
illustrate program flow. It seems the printf() calls are affecting timing
more than I expected though. If I switch to the console’s virtual screen the
filter crashes due to the time required to display the printf() to the
screen. If I sit on some other virtual screen everything works happily.
Then, when my filter crashes (for other reasons), I can switch over to the
console to get the post-mortem (the last screen-full of printf()). Now that
I’ve explained my current system of debugging, can anyone here give me
suggestions for a better method?
I also use gdb to analyze the core dump, but the information I need is
usually long lost by then. I can at least tell which module I crashed (below
me, or above me) but by then my module that caused the crash is well past
the actual problem point.
My primary debug tool is gdb, on runtime, for logical error.
Once it gets into a “timing” issue, printf(), or if that changes
the timing, try “slogf()”. Another way is malloc() a large chunk
of memory, and dump your data into it. So, in core dump, you can
check the log.
Gdb for core dump is not that bad. especially if you are running
the debug version of your dll. You will have back trace, stack
frames, variables. Even if you are not running debug version,
you should still be able to figure out the back trace (which
of your function get called before crash), parameters (what
did you pass to another layer) from the stack.
-xtang
Hmmm, I thought that cadillac tool for real-time debugging was
TraceEvent. I haven’t used it yet on QNX6, but on QNX4 I have debugged
many real-time apps using Trace.
Xiaodan Tang wrote:
Shaun Jackman <> sjackman@nospam.vortek.com> > wrote:
Debugging io-net modules is making my head hurt. I expect you can all
sympathise. My chief tool to date has been printf() in key places to
illustrate program flow. It seems the printf() calls are affecting timing
more than I expected though. If I switch to the console’s virtual screen the
filter crashes due to the time required to display the printf() to the
screen. If I sit on some other virtual screen everything works happily.
Then, when my filter crashes (for other reasons), I can switch over to the
console to get the post-mortem (the last screen-full of printf()). Now that
I’ve explained my current system of debugging, can anyone here give me
suggestions for a better method?
I also use gdb to analyze the core dump, but the information I need is
usually long lost by then. I can at least tell which module I crashed (below
me, or above me) but by then my module that caused the crash is well past
the actual problem point.
My primary debug tool is gdb, on runtime, for logical error.
Once it gets into a “timing” issue, printf(), or if that changes
the timing, try “slogf()”. Another way is malloc() a large chunk
of memory, and dump your data into it. So, in core dump, you can
check the log.
Gdb for core dump is not that bad. especially if you are running
the debug version of your dll. You will have back trace, stack
frames, variables. Even if you are not running debug version,
you should still be able to figure out the back trace (which
of your function get called before crash), parameters (what
did you pass to another layer) from the stack.
-xtang
\
Rennie Allen <rallen@csical.com> wrote:
Hmmm, I thought that cadillac tool for real-time debugging was
TraceEvent. I haven’t used it yet on QNX6, but on QNX4 I have debugged
many real-time apps using Trace.
Ah, yes, that one too. On QNX6 it’s slogger, slog*(), and sloginfo 
-xtang
Xiaodan Tang wrote:
Shaun Jackman <> sjackman@nospam.vortek.com> > wrote:
Debugging io-net modules is making my head hurt. I expect you can all
sympathise. My chief tool to date has been printf() in key places to
illustrate program flow. It seems the printf() calls are affecting timing
more than I expected though. If I switch to the console’s virtual screen the
filter crashes due to the time required to display the printf() to the
screen. If I sit on some other virtual screen everything works happily.
Then, when my filter crashes (for other reasons), I can switch over to the
console to get the post-mortem (the last screen-full of printf()). Now that
I’ve explained my current system of debugging, can anyone here give me
suggestions for a better method?
I also use gdb to analyze the core dump, but the information I need is
usually long lost by then. I can at least tell which module I crashed (below
me, or above me) but by then my module that caused the crash is well past
the actual problem point.
My primary debug tool is gdb, on runtime, for logical error.
Once it gets into a “timing” issue, printf(), or if that changes
the timing, try “slogf()”. Another way is malloc() a large chunk
of memory, and dump your data into it. So, in core dump, you can
check the log.
Gdb for core dump is not that bad. especially if you are running
the debug version of your dll. You will have back trace, stack
frames, variables. Even if you are not running debug version,
you should still be able to figure out the back trace (which
of your function get called before crash), parameters (what
did you pass to another layer) from the stack.
-xtang
\
David Gibbs wrote:
The closest equivalent to the QNX4 Trace() API would be the
TraceEvent() call with some of the INSERT event modes.
This does require the instrumented kernel – under 6.1 this was
shipped with System Analysis Toolkit. With QNX Momentics (6.2),
I’m not so sure how this has been packaged. It seems to be included
with Pofessional Edition (PE), but I’m not sure about the other
editions.
Hmmm, this could be a problem. One of the reasons (I suspect) that QSSL
has made the DDK’s free (perhaps I’m wrong) is to try and develop a base
of open drivers for some of the less common hardware out there. Having
TraceEvent, would certainly make it easier for people to develop drivers.
Rennie
I read “The Instrumented Microkernel”:
http://qdn.qnx.com/support/docs/neutrino_2.11_en/sys_arch/trace.html
but found myself with two lingering questions: Where do I get an
instrumented kernel, and where are the tracelogger and traceprinter
utilities? I can’t seem to find either of them. A trivial question I’m sure,
but it would be nice if the above doc answered it directly.
Cheers,
Shaun
Hmmm, I thought that cadillac tool for real-time debugging was
TraceEvent. I haven’t used it yet on QNX6, but on QNX4 I have debugged
many real-time apps using Trace.
Agreed. My only problem with the QNX4 implementation was that the trace
buffer was never big enough. I have to debug audio device drivers and
needed to log as many as 1000 events a second. I used their technique and
developed my own event logging system. Now I have a display utility where I
can say show me this level of detail except while during that action then
show me this level of detail.
“Rennie Allen” <rallen@csical.com> wrote in message
news:3D085DA5.4030202@csical.com…
Hmmm, I thought that cadillac tool for real-time debugging was
TraceEvent. I haven’t used it yet on QNX6, but on QNX4 I have debugged
many real-time apps using Trace.
Xiaodan Tang wrote:
Shaun Jackman <> sjackman@nospam.vortek.com> > wrote:
Debugging io-net modules is making my head hurt. I expect you can all
sympathise. My chief tool to date has been printf() in key places to
illustrate program flow. It seems the printf() calls are affecting
timing
more than I expected though. If I switch to the console’s virtual screen
the
filter crashes due to the time required to display the printf() to the
screen. If I sit on some other virtual screen everything works happily.
Then, when my filter crashes (for other reasons), I can switch over to
the
console to get the post-mortem (the last screen-full of printf()). Now
that
I’ve explained my current system of debugging, can anyone here give me
suggestions for a better method?
I also use gdb to analyze the core dump, but the information I need is
usually long lost by then. I can at least tell which module I crashed
(below
me, or above me) but by then my module that caused the crash is well
past
the actual problem point.
My primary debug tool is gdb, on runtime, for logical error.
Once it gets into a “timing” issue, printf(), or if that changes
the timing, try “slogf()”. Another way is malloc() a large chunk
of memory, and dump your data into it. So, in core dump, you can
check the log.
Gdb for core dump is not that bad. especially if you are running
the debug version of your dll. You will have back trace, stack
frames, variables. Even if you are not running debug version,
you should still be able to figure out the back trace (which
of your function get called before crash), parameters (what
did you pass to another layer) from the stack.
-xtang
“Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:
Agreed. My only problem with the QNX4 implementation was that the trace
buffer was never big enough. I have to debug audio device drivers and
needed to log as many as 1000 events a second. I used their technique and
developed my own event logging system. Now I have a display utility where I
can say show me this level of detail except while during that action then
show me this level of detail.
Under QNX4, you could modify the size the trace buffer with the
-T option to Proc32.
Somebody mentioned slogf() as a replacement for QNX4’s Trace – it
is not the same. slogf() and family are close to syslog() from a
traditional Unix – they are built on top of MsgSend().
The closest equivalent to the QNX4 Trace() API would be the
TraceEvent() call with some of the INSERT event modes.
This does require the instrumented kernel – under 6.1 this was
shipped with System Analysis Toolkit. With QNX Momentics (6.2),
I’m not so sure how this has been packaged. It seems to be included
with Pofessional Edition (PE), but I’m not sure about the other
editions.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:aeat2m$nuq$2@nntp.qnx.com…
“Bill Caroselli (Q-TPS)” <> QTPS@earthlink.net> > wrote:
Agreed. My only problem with the QNX4 implementation was that the trace
buffer was never big enough. I have to debug audio device drivers and
needed to log as many as 1000 events a second. I used their technique
and
developed my own event logging system. Now I have a display utility
where I
can say show me this level of detail except while during that action
then
show me this level of detail.
Under QNX4, you could modify the size the trace buffer with the
-T option to Proc32.
I know but it was limited to 64K. I typically use a buffer of 2 - 4 MB.