I love debugging..

All off topic discussions go here. Everything from the funny thing your cat did to your favorite tv shows. Non-programming computer questions are ok too.
Post Reply
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

I love debugging..

Post by mystran »

I just love debugging, and especially the art of fitting as much debugging info in easily readable format on screen, as possible...

This time my OS console looked like below, when I finally found 'da bug in my new blockcache code: I forgot to update cache->lru.last when removing block from a lru-list. If somebody cares, the lru-list is currently singly-linked list, but with pointers to first and last element to make it easier to add entries at the end.. should make it double linked list I guess.

Anyway, the beauty of debugging:

edit: to be absolutely clear, that's a shot from the first successful test run after testing the code, but you get the point
Attachments
voix-2007-04-27-debugging.png
voix-2007-04-27-debugging.png (35.34 KiB) Viewed 688 times
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

Actually, I'll torture you with another.... this is what happens when your malloc doesn't keep a separate free list, instead just scanning over all the blocks. Brown stuff is malloc output, with '-' for each scanned used block, '+' for each free block that's too small, and '#' for the final selected allocation block.

Output is after running 'ls' and waiting for a few clockticks to pass. Not quite what one would hope. ;)
Attachments
voix-2007-04-27-badmalloc.png
voix-2007-04-27-badmalloc.png (53.01 KiB) Viewed 681 times
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Post Reply