|
|
The Icon Bar: Programming: Debugging tips
| |
Debugging tips |
| |
ksattic (22:41 22/1/2004)
Phlamethrower (22:54 22/1/2004)
ksattic (00:02 23/1/2004)
Phlamethrower (00:51 23/1/2004)
adrianl (03:00 23/1/2004)
ksattic (03:25 23/1/2004)
Phlamethrower (00:44 12/8/2008)
|
| |
|
Simon Wilson |
Message #50094, posted by ksattic at 22:41, 22/1/2004 |
 Finally, an avatar!
Posts: 1291
|
Does anyone have any debugging tips for RISC OS C programs? One of my programs is behaving very eratically (freezing the machine on some occasions) and I can't think of how to track down the problem. Is there any way to spot bad memory references without going through every single line of code with a fine-toothed comb? |
| |
 [ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #50095, posted by Phlamethrower at 22:54, 22/1/2004, in reply to message #50094 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
There's my little module GrabErr, which could be of some help (It isn't 32bit yet though). Adding some debugging code would be a good idea too (e.g. just printf'ing to stderr, which is then redirected to a file when you run the program). Stuff like which pointers are being used in functions, etc.
I find that most of my pointer problems come from dodgy linked list handling code, or from not zeroing a pointer which has been freed.
If you're using GCC and get really desperate then you can also turn on the -finstrument-function option and write some code to print out a trace of your program (Be warned that there are bugs in all the release versions of GCC, but I can tell you how to fix/get round them if this is what you're after).
Hope that helps  |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #50099, posted by ksattic at 00:02, 23/1/2004, in reply to message #50095 |
Finally, an avatar!
Posts: 1291
|
Thanks for the tips - I've already added plenty of debugging code (printfs and fflushes), but I've got a feeling I'm doing something *really* stupid.
Firstly, when I tried compiling my C code with -O3, it broke one of my functions. I managed to fix the function so it worked again, but I really can't see why -O3 would do that. I've a feeling -O3 is the same as -O2 on RISC OS gcc anyway.
Secondly, my program is causing the computer to freeze for seven seconds at a time (when I click on buttons in the Wimp app), then I need to power-cycle before I'm able to load my program again without freezing the machine permanently. This makes me think I'm seriously corrupting some memory.
Edit: Knowing me, it's highly likely I'm doing something stupid with the hardware I'm controlling - the TV card. It has a DMA controller on-board so for all I know I could be hanging the PCI bus! I made my program talk to an area of memory I allocated with malloc() rather than the PCI card registers and the freezing went away, so I'll just have to look closer at what I'm doing with the card (with plenty of printfs).
[Edited by ksattic at 00:21, 23/1/2004] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #50103, posted by Phlamethrower at 00:51, 23/1/2004, in reply to message #50099 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Secondly, my program is causing the computer to freeze for seven seconds at a time (when I click on buttons in the Wimp app), then I need to power-cycle before I'm able to load my program again without freezing the machine permanently. This makes me think I'm seriously corrupting some memory. Sounds like some kind of runaway loop to me.
I made my program talk to an area of memory I allocated with malloc() rather than the PCI card registers and the freezing went away, so I'll just have to look closer at what I'm doing with the card (with plenty of printfs). Good luck  |
| |
[ Log in to reply ] |
| |
|
Adrian Lees |
Message #50108, posted by adrianl at 03:00, 23/1/2004, in reply to message #50103 |
Member
Posts: 1637
|
Have you been following the "Freezing (rows & columns)" thread on the Iyonix support group? I'd check out Pulse(2) and see whether they cause failures on your machine. If so, you may want to try John's hardware mod in case the problem affects your DMA transfers too.
When you say 'freezes for 7 seconds' what happens during that time? Can you move the mouse pointer and/or toggle the keyboard LEDs. 7 seconds is a long time in hardware terms; a hardware-level problem would be unlikely to recover after such a long delay.... I'd expect it's a software problem,
or perhaps software waiting for a stalled DMA to complete, giving up and (eventually) timing out?
I don't know the details of -O2/O3 but if the offending function is accessing hardware, be sure to use pointers to volatile types (eg. volatile char *pCard) otherwise writes can be reordered or dropped altogether.
Also note that writes are not 'flush out' to the card straightaway; they can be buffered in the IOP321 and PCI bridge. If subsequent code relies upon the write having completed (especially clearing IRQs), you need to read back from that written address to force completion of the write.
Lastly, and sorry if this (or any of the above) is insulting, remember that the logical->physical memory mapping isn't guaranteed and can change. I don't think this affects you, though, since your DMA is from card to card rather than via the system memory, right?
Conversely, if you need more info, please ask. |
| |
[ Log in to reply ] |
| |
|
Simon Wilson |
Message #50109, posted by ksattic at 03:25, 23/1/2004, in reply to message #50108 |
Finally, an avatar!
Posts: 1291
|
I think I may have found the problem - I was fiddling with the PLL on the TV card while the decoder was still using it, so stopping the decoder from using the PLL before I altered it helped a lot. 
When I said freeze, I meant that the mouse stopped moving and the keyboard LEDs wouldn't toggle.
I tried one of the pulse programs, but it didn't freeze my machine. I'll try to catch up with the thread.
With regard to the -O3 screwing up a function, the first thing I tried was the "volatile" keyword, with no effect. I will look closer at the function later.
Also note that writes are not 'flush out' to the card straightaway; they can be buffered in the IOP321 and PCI bridge. If subsequent code relies upon the write having completed (especially clearing IRQs), you need to read back from that written address to force completion of the write. Ah, thanks for the tip. I presume writes are in order, though - I think that's the only thing my software requires to function.
Lastly, and sorry if this (or any of the above) is insulting, remember that the logical->physical memory mapping isn't guaranteed and can change. I don't think this affects you, though, since your DMA is from card to card rather than via the system memory, right? Yes, the TV card has a DMA controller to write data directly to the video memory.
I'm using PCI_HardwareAddress (with R0=0x200 for user mode r/w) for the card I/O and I'm making sure I use the logical address in my user program. I was until recently writing to memory allocated by PCI_RamAlloc in user code, even though the PCI docs say this is not possible. I'm now using assembler routines to perform the writes. John Ballance was kind enough to write these routines for me - I don't have the necessary assembly knowledge.
Cheers for the help, both of you! |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #108002, posted by Phlamethrower at 00:44, 12/8/2008, in reply to message #50095 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I find that most of my pointer problems come from dodgy linked list handling code, And this is still true almost 5 years later. Wah!
(Although I did find several other non linked list related bugs along my way, and have added a few reams of debugging code to help track down what goes wrong in the future) |
| |
[ Log in to reply ] |
| |
|
The Icon Bar: Programming: Debugging tips | |
|
