Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Friday August 01, 2008
11:38 PM

I Can Fix That Bug in One Character....

[ #37082 ]

If it's not a hoary aphorism by now, it should be: many bugfixes are trivial once you understand the problem.

Parrot's new concurrency branch is almost ready to merge back to the trunk. It's taken quite a while to reach this point for various reasons. Some of that is due to the complexity of the changes, which replace a couple of deep subsystems of Parrot. (Many languages and libraries built on Parrot have some idea about how control flow works, and changing that -- even slightly -- has repercussions.) Allison is the primary developer of this branch, despite spending the past six months working furiously on OSCON. I've helped somewhat, but my schedule has also been tight. Admittedly, I probably should have forced her to give me more work, but hindsight is always more accurate than foresight.

When she's in town, sometimes she crashes in one of my spare rooms. Sometimes we get a chance to hack on the same code. Tonight, however, she went out to dinner with mutual friends. I decided to stay home to recuperate from the past several weeks. Before she left, she said that a few HLL tests still failed on her branch.

While the Dr. Who season finale was recording, I took a look. Plenty of Rakudo tests failed when throwing an exception, claiming that there was no valid exception handler in place.

I traced the code, and discovered that the problem actually came from rethrowing an exception within an active exception handler. The problem comes from the Parrot compiler tools, which uses exceptions to manage some of its control flow. In particular, it throws a specific type of exception to indicate return from certain constructs within generated code.

The generated exception handler queries the exceptions it catches, then checks if they're return-type exceptions. If they aren't, it rethrows them.

None of the problematic exceptions were return-type exceptions, though all of them should have been. I poked at the code for a while, then dug into PCT to examine how it generates code. Fortunately, code generators is easy to grep (sorry, ack). Of the two instances of instantiating Exception PMCs, only one spot set the type of the exception -- and to the correct value.

Unfortunately, it used the syntax exception['_type'] = .CONTROL_RETURN. The new Exception PMC calls its type member type.

Deleting the leading underscore in fixed the problem, and now Rakudo passes all of its tests on the concurrency branch. I suspect that other PCT-based languages with similar failures now work. See Parrot r29933 for the smallest yet most useful commit I've made in a while. I like fixing bugs by deleting code, though usually I prefer to delete more than one character.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.