[haiku-development] Re: Jamming in debugging info?

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 15 Jul 2009 12:51:25 +0200

On 2009-07-15 at 04:19:57 [+0200], pete.goodeve@xxxxxxxxxxxx wrote:
> On Tue, Jul 14, 2009 at 04:16:50PM +0200, Ingo Weinhold wrote:
> I think I'll defer that ticket... Turns out that it only occurs due to
> some "minor" changes I made (:-/).   The problem is that the critical line
> is just a dprintf statement, and is nowhere near where the fault occurs!
> Just for reference, here's the section:
> 
>     DPRINTF_INFO((MY_ID "issue bulk xfer ep0\n"));
>     /* issue bulk transfer */
>     my_dev->ept = &intf->endpoint [0];        /* interrupt IN */
>     st = usb->queue_bulk (my_dev->ept->handle, my_dev->buffer,
>         my_dev->total_report_size, midi_usb_callback, my_dev);
>     if (st != B_OK) {
>         DPRINTF_ERR ((MY_ID "queue_bulk() error %d\n", (int)st));
>         return B_ERROR;
>     }
> 
> I added that DPRINTF_INFO line (defined as dprintf in the header) when
> I was trying to trace things, but it is only one among many, and is the
> only one that causes the KDL if it isn't commented out.  The crash, as
> I said, actually occurs in the midi_usb_callback function.
> 
> (There are other KDLs that happen, which helped to confuse me, but
> they seem to be due to things like the driver not getting shut down
> properly on exit.  Looking at that comes later...)
> 
> So what can be the hazards of using dprintf?

The only problem I know of, is that dprintf() must not be called with 
interrupts disabled, since it potentially writes to a port. That only 
triggers a panic though and doesn't cause any weird crashes. 
dprintf_no_syslog() should be used in respective places.

Other than that, generally any adding of code might change the location of 
other code. That shouldn't have any runtime effect on correct code, but buggy 
code (e.g. as in using bad pointers) might behave differently.

So it's not unlikely there's a bug somewhere. I would start with the crashing 
instruction and track back where the dereferenced pointer comes from. If you 
need help with this, please post the disassembled code of the function in 
question and, if you've modified it, its source code, too.

CU, Ingo

Other related posts: