Slash Boxes
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 ]

Whiteknight (8626)

  (email not shown publicly)
http://en.wikibo ... User:Whiteknight
AOL IM: wknight8111 (Add Buddy, Send Message)

My name's Andrew. I'm an open-content advocate at I'm also involved with Parrot as a semi-competent C hacker. This blog is going to be a forum where I can ramble about minutia and post information about perl-world stuff that I care about.

Journal of Whiteknight (8626)

Monday July 07, 2008
10:52 AM


[ #36863 ]

I picked up work this morning, coming back from the nice three-day weekend. Unfortunately, I have hit a bit of a roadblock and cannot seem to figure out where the problem lies.

What I am trying to do now is to get the build process to complete. At the moment, building fails at the following step, in compilers/pge: ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/

Most of the build steps up to this point that require parrot are very short and simple, and none of them that I can see trigger a full GC run. I've added a series of diagnostic messages to trace the execution path of this step, and the answers that I find are quite perplexing. The GC finishes a complete run in batch mode. After the GC run completes, the program segfaults.

My initial assumption is that somewhere I am freeing an object that should not be freed, attempting to reuse a pointer from a freed object, and segfaulting that way. So, I comment out the function calls to the sweep code, and try to build again. Same result. I think that maybe a call to gc_it_add_free_object is freeing an object that should not be freed, so I comment that function out. Same result. The GC at this point is simply not freeing any objects. We perform the normal allocation functions and the mark phase, but we do not sweep or recycle any usused objects after they have been marked dead.

So I fire up GDB and run that step in the debugger. GDB tells me that the error is occurring in a memcpy call from src/strings.c:Parrot_unmake_COW. So, I go into that function, add a few PARROT_ASSERT() calls and diagnostic messages and...Same Result. I mean, the result was exactly the same, no diagnostic messages printed out (even though it should be printing a few things before any pointers are dereferenced), no assertions fail, nothing. If it weren't for the debugger telling me that the error is occuring here, I wouldn't believe that this function is being called anywhere near the segfault.

However, if it is a problem with strings (and I don't doubt necessarily that it could be), I figure I'll poke around with them a little bit more. I go to src/headers.c:get_string_header and make extra certain to initialize all fields in the new string header, especially all pointers. Again, nothing changes.

I'm going to play around with my allocators now, to ensure they are returning proper pointers. after that, I'm diving back into GDB to single-step my way through the entire program (or, the important parts of it anyway). Hopefully, I can get this particular problem solved and soon.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • That reminds me a little bit of Parrot RT #51652 []. I'm not sure it's the same problem, but that part of Parrot can be a little fragile.

    • Good call. The ticket number is right even though the link is wrong.

      I added in a few statements to test for the basic isomorphisms that I've been relying on:

              PARROT_ASSERT(offsetof(Buffer, flags) == offsetof(PObj, flags));
              PARROT_ASSERT(offsetof(Buffer, flags) == offsetof(PMC, flags));
              PARROT_ASSERT(offsetof(Buffer, flags) == offsetof(STRING, flags));
              PARROT_ASSERT(offsetof(Buffer, flags) == offse

      Andrew Whitworth