soma

Hello and welcome to my super magical web 2.0 synergetic "blog" (what a miserable term). Anyways, I cannot guarantee anything I write here is coherent, or correct in any sense. Sorry. I'm anxiously awaiting somebody to hire me as a QA Engineer, since I obviously am good at breaking software. You can contact me via tyler@bleepsoft.com if you'd like to berate me for anything I've written here :)


24/08 you can call me the exterminator

I've been working on consulting code for a company that will rename nameless. They contracted some of their software development out of firm a while back, and have been hampered with this set of code ever since, and brought me in to fix their Mac and Linux code. The code has been a true exercise in futility, I've had sub-processes SIGSEGV shortly after attaching gdb(1) to them, and watched as modules would die out for no apparent reason.

After days and days of staring at code, screaming, watching logging output, pagan rituals, and general debuggery, I finally found the bug.

I isolated the bug to a specific module, and then to a helper process that is run along side that module, and eventually found the problem, about 8 or 9 lines of code that resemble this:

someToken = strtok(NULL, "\t ");
someVar = atoi(someToken);


Yikes.

[tags: , , , , ]

29/07 Found: OpenBSD NFS Kernel Bug

I was recently given the task to track down, and annihilate a bug in OpenBSD's NFS implementation that was affecting a friend of mine's hosting operation. His setup seems relatively basic and solid for a small hosting company, a main NFS server packed with disks, running FreeBSD, serving the home directories as well as some other shares to a good heterogeneous mix of both OpenBSD and FreeBSD mail, web and shell servers. The bug, which had been previously reported in pr #3210, would occur in certain programs when their PID (process ID) would receive a signal of any kind (I tested with only SIGINT and SIGKILL since my machine for testing is 6 years old).


After a good three or four days of testing, kernel recompiles, AnonCVS checkouts, locking up the machine, examining the kernel via ddb(4) and several cans of Coke, I had narrowed the bug down to a specific set of test cases, and had all the information to start writing code. I am by no means a kernel hacker (it is one of those life long goals, next to running for president though), I have never researched this small amount of code for so long before. The code that contained the bug was within about ~200 lines of code deep in the VFS layer upon which all of OpenBSD's NFS code sits (as well as their msdosfs and ext2fs code). Because of the similarities between both OpenBSD and NetBSD's kernels, the bug may also exist in NetBSD's VFS layer. I have posted to the tech@openbsd.org mailing list with my findings, and have uploaded my patch as well: vfs_bio.c.diff. Thanks to Thomas E. Spanjaard (TGEN on Freenode) for creating a patch for NetBSD (although he could not test it without setting up an NFS server): vfs_bio.c.nbsd.diff

Read the full entry »

10/07 The CoreFoundation Bug Revisited.


The bug I outlined with this post has been not only been updated, i.e. I'm closer to pegging the bug down, but my previous bug report (rdar://problem/4570035) now has been "split" into two bug reports by the Apple engineering folks, so now rdar://problem/4563964 exists as well.



So, what's changed? For about a week, I was running iChat without Chax, but lacking tabs was killing me...so I reinstalled Chax, and BAM! I hit the bug again except this time with iPhoto, instead of just Preview, and Mail.app, I also found a crash log from cc1obj, which crashed at the same time as iPhoto.



The temporary solution has been to use the latest Adium beta instead of Chax, which has been uninstalled from the system. But the question still remains...can you find this bug?




Check out today's crash logs: iPhoto.crash.log & cc1obj.crash.log
As well as the previous crash logs: Mail.crash.log & Preview.crash.log




[tags: , , , , , , ]
www.flickr.com