Camelia, the Perl 6 bug

IRC log for #parrot, 2009-07-04

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:36 Austin_Hastings Anyone know whether or not it's possible to use function pointers/references/call-via-scalar-string in NQP? If so, how?
01:39 pmichaud Austin_Hastings: It's not directly possible at the moment, but it's something we could easily add.
01:39 Austin_Hastings Pmichaud: Thanks, but I'm just finishing the elsif chain... :(
02:28 whoppix joined #parrot
02:35 janus joined #parrot
03:48 Austin_Hastings left #parrot
04:03 Theory joined #parrot
04:22 Andy joined #parrot
06:08 flh joined #parrot
06:23 iblechbot joined #parrot
06:28 cotto joined #parrot
06:56 dalek TT #808 created by flh++: VIM syntax file: fix parsing of quoted ".end"
07:03 Zak joined #parrot
07:19 szabgab joined #parrot
08:02 mikehh All tests PASS (pre/post config, smolder, fulltest) at r39872 - Ubuntu 9.04 amd64
09:05 barney joined #parrot
10:08 janus joined #parrot
10:09 preflex joined #parrot
10:31 bacek joined #parrot
10:45 masak joined #parrot
11:00 dalek parrot: r39873 | fperrad++ | trunk/include/parrot/thr_windows.h:
11:00 flh joined #parrot
11:00 dalek parrot: [build] MinGW gcc 4.4.0
11:00 dalek parrot: with this version, a include pthread.h is supplied,
11:00 dalek parrot: which defines struct timespec with a guard named HAVE_STRUCT_TIMESPEC.
11:00 dalek parrot: So, rename the guard in thr_windows.h
11:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39873/
12:22 iblechbot joined #parrot
12:23 dalek TT #771 closed by bacek++: [bug] Duplicate identifier in Test;More.is_deeply
12:23 dalek parrot: r39874 | bacek++ | trunk/runtime/parrot/library/Test/More.pir:
12:23 dalek parrot: [cage] Rename duplicated C<left> and C<right> variables in Test/More.pir
12:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39874/
12:28 kid51 joined #parrot
12:38 MoC joined #parrot
13:01 Whiteknight joined #parrot
13:02 skids joined #parrot
13:07 flh ping kid51?
13:07 purl I can't find kid51? in the DNS.
13:08 flh kid51, did you run "make vim-install" in editor/ after applying the patch?
13:09 kid51 No, I did not.
13:10 flh vim uses the ~/.vim/syntax/pir.vim file, which is only updated by "make vim-install"
13:10 kid51 Okay, I was unaware of that.
13:16 dalek parrot: r39875 | jkeenan++ | trunk/editor/pir_vim.in:
13:16 dalek parrot: Enable Vim to correctly handle quoted string ".end" in subroutines.  Cf. https://trac.parrot.org/parrot/ticket/808; applying patch submitted by flh++.
13:17 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39875/
13:20 dalek TT #808 closed by jkeenan++: VIM syntax file: fix parsing of quoted ".end"
13:34 bacek joined #parrot
13:35 PacoLinux NotFound: en el tercer parrafo de docs/book/draft/ch06_nqp.pod hay un error - NQP represets almost - <-- represents :: lo puedes cambiar ?
13:36 riffraff joined #parrot
13:36 PacoLinux wrong channel :)
13:43 MoC question: does building parrot trunk rev. 39873 or greater work on linux?
13:44 Theory_ joined #parrot
13:44 kid51 MoC:  works for me
13:45 MoC hrm... because I thought that Linux explicitly uses _STRUCT_TIMESPEC to avoid redefinition...
13:45 MoC and rev. 39873 changed it to HAVE_, but if it still works, nevermind
13:47 dalek parrot: r39876 | jkeenan++ | trunk/docs/book/draft/ch06_nqp.pod:
13:47 dalek parrot: Correct spelling error noted by PacoLinux.
13:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39876/
13:49 kid51 MoC:  While it has not affected my subsequent builds on Linux, you should feel free to post a question about that on list to fperrad (who is rarely on #parrot).
13:50 kid51 MoC:  Since the commit message mentions MinGW, I suspect this change was for Win32 users' benefit.
13:50 kid51 But I don't know what other side effects it might have.
13:50 MoC yep, I already planned to do that, in case of possible future errors
13:50 ruoso joined #parrot
13:50 kid51 PacoLinux:  Lo cambi�.
13:51 PacoLinux kid51: gracias :)
13:52 MoC "MoC:  Since the commit message mentions MinGW, I suspect this change was for Win32 users' benefit." <-- yep. Before that commit I had to edit pthread.h itself.
13:53 kid51 MoC:  Am now running Smolder test.  Will report any problems related to 39873.
13:53 dalek parrot: r39877 | fperrad++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
13:53 dalek parrot: [pmc]
13:54 dalek parrot: with dynpmc, don't generate PARROT_EXPORT,
13:54 dalek parrot: but PARROT_DYNEXT_EXPORT
13:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39877/
13:58 Whiteknight joined #parrot
13:59 MoC kid51: Nevermind about that change breaking something on a non-windows OS. I overlooked that he only changed thr_windows.h, which appears to be only included on windows hosts. I will however still write a mail to the list, since I think that the issue is with pthread.h, because other software also uses _STRUCT_TIMESPEC instead of HAVE_*
14:05 kid51 MoC:  good analysis; please post
14:05 kid51 ... post to list
14:06 kid51 ... or create TT, if appropriate
14:06 MoC I suppose a post to the mailing list is sufficient
14:07 dalek parrot: r39878 | fperrad++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
14:07 dalek parrot: [pmc] improve layout
14:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39878/
14:10 kid51 Confirmed by successful Smolder test http://smolder.plusthree.com/app/pu​blic_projects/report_details/24479
14:26 MoC Ok. Mail sent.
15:00 * Whiteknight thinks he might have solved the GC heisenbug
15:00 Whiteknight or, at least one part of it
15:00 davidfetter but only if the isotope has decayed?
15:01 Andy joined #parrot
15:03 kid51 GC heisenbug => Unfreed memory disappears if you look at it, but then immediately reappears.
15:05 Infinoid Whiteknight++
15:05 Whiteknight commit coming now, you're going to like this one Infinoid
15:06 Whiteknight a real bear to track down
15:06 Infinoid I've put in some work adding valgrind annotations but it didn't really catch much.  Glad to see someone else has been making more progress :)
15:07 Infinoid I'd like to add some padding between PMC structures within the arenas, and stagger reallocation so that (for instance) if PMC is 48 bytes in a 64-byte structure, the first time it's allocated at offset 0, the next time at offset 8, the next time at offset 16, and throw up some red zones to catch old pointers
15:08 Infinoid 48 bytes of structure in a 64-byte zone, I mean
15:08 Whiteknight that's not a bad idea
15:08 Infinoid But I have a question.
15:08 dalek parrot: r39879 | whiteknight++ | trunk/src/oo.c:
15:08 dalek parrot: [gc] fix one gc heisenbug, although apparently this isn't the only one. When cloning an object, we get into situations where we mark the object before it's ATTRs struct is initialized. This causes whatever garbage was in that allocated memory to be passed to the GC for marking, and hilarity ensues. Zero out the struct here to ensure we have NULL values in the struct and then Parrot_Object_mark won't try to mark the NULL pointers
15:08 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39879/
15:08 Whiteknight a little wasteful, so we should be able to turn that feature off
15:08 Whiteknight what's your question?
15:08 Infinoid Of all the fields of the PMC structure, are the first ones most likely to be accessed, or the last ones?
15:08 Infinoid That will determine whether we should precess forward or backward
15:08 Whiteknight let me look at it again
15:09 Infinoid There's too much smoke and mirrors in the pobj/pmc structure definition, I'm still not really sure how they are built
15:09 Infinoid I was wanting to look again, it's just an idea that occurred to me in the shower
15:09 Whiteknight flags, vtable, and pmc_ext are the most frequently used, I think
15:09 Whiteknight I don't think data is used at all
15:09 Whiteknight or, maybe it is and I never noticed
15:10 hudnix_ joined #parrot
15:10 jonathan Whiteknight++ # nice work!
15:10 Infinoid Whiteknight++ indeed
15:11 Infinoid So I haven't made a lot of progress with valgrind, though its memcheck.h API does give us some interesting possibilities
15:11 Infinoid I can explicitly tell it that all the fields in the PMC structure are "undefined" when it's pulled from the free list, for example
15:12 Infinoid and I can make them unreachable when it's put back on the free list
15:12 Infinoid The problem is, when it's reallocated, that doesn't help much, hence the offset allocation idea
15:15 Infinoid hmm.  I can also put an implicit read barrier into the PMC_* macros to check whether the PMC was reallocated with a different offset
15:15 Infinoid ... or, on x86-64 at least, we can build a serial number or some kind of cookie into the highest bits of the pointer value itself
15:16 Infinoid assuming nothing accesses them without going through those macros...
15:21 Whiteknight nopaste?
15:21 purl nopaste is, like, at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others) or http://gist.github.com/
15:21 clunker3 http://pasta.test-smoke.org/ or http://paste.husk.org/ or http://nopaste.snit.ch:8001/ or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/
15:22 nopaste "Whiteknight" at 69.248.162.161 pasted "new segfault, happens in P6Invocation" (45 lines) at http://nopaste.snit.ch/17110
15:22 Whiteknight jonathan: take a look at that backtrace please
15:22 Whiteknight I'll dig into it now, but you probably know the code better then I do
15:25 jonathan Whiteknight: Ah, that's new-ish code, that hasn't had a bug found in it yet. It's probably about time. ;-)
15:25 jonathan oh, it crashes inside the multi dispatcher.
15:25 jonathan Interesting.
15:25 Whiteknight the pos_args parameter has ->vtable == 0xdeadbeef
15:26 Whiteknight so it's been prematurely collected at some point
15:26 jonathan Ah
15:26 jonathan This works with -G?
15:26 Whiteknight it's that same incantation that bacek sent me
15:26 jonathan I can tell you for sure that pos_args only ever exists on the stack.
15:26 Whiteknight I don't know if -G fixes it
15:27 Whiteknight here's the command I used: gdb --args ../../parrot -R gcdebug --gc-debug ./perl6.pbc t/spec/S04-statements/do.rakudo
15:27 Whiteknight so it might disappear with -G, or even if we omit --gc-debug
15:27 jonathan Aye, but it still shouldn't be getting collected.
15:27 Whiteknight true
15:28 jonathan PMC *pos_args, *named_args;
15:28 jonathan get_args(interp, &pos_args, &named_args);
15:28 jonathan get_args should be setting those.
15:28 pmichaud re: r39879 (Whiteknight++) ---   shouldn't mem_allocate_typed zero out the pointers and fields by default?
15:28 jonathan I did extensively refactor that code recently, let me sanity check.
15:29 Whiteknight pmichaud: I don't know what it *should* do, but I can tell you what it isn't doing
15:29 jonathan pmichaud: That's mem_allocate_zeroed_typed IIRC.
15:29 jonathan Or similar.
15:29 purl rumour has it similar is happening in Rakudo
15:29 pmichaud then perhaps we should be calling mem_allocate_zeroed_typed
15:29 Whiteknight does that function even exist?
15:29 pmichaud I'm wondering when it would be appropriate to call mem_allocate_typed
15:29 Infinoid yes, it exists
15:30 Whiteknight I don't see it in src/gc/alloc_memory.c
15:30 Infinoid memory.h:#define mem_allocate_zeroed_typed(type)     (type *)mem_sys_allocate_zeroed(sizeof (type))
15:30 jonathan Whiteknight: In get_args it does
15:30 jonathan PMC    * const arg_list       = pmc_new(interp, enum_class_ResizablePMCArray);
15:30 jonathan PMC    * const arg_hash       = pmc_new(interp, enum_class_Hash);
15:30 jonathan And later
15:30 jonathan *pos_args   = arg_list;
15:30 jonathan *named_args = arg_hash;
15:30 jonathan Where pos_args and named_args are pointes to PMC pointers.
15:30 jonathan (e.g. to set them in the caller)
15:31 jonathan So I'm pretty sure they're always on the stack.
15:31 pmichaud ...what keeps them from being gc'ed?
15:31 jonathan Anyway, the relevant code is all inside perl6multisub.pmc
15:31 jonathan Not p6invocation.pmc
15:31 jonathan pmichaud: The GC walks the stack. In theory.
15:31 Whiteknight ah nevermind, it's defined in a #define
15:31 pmichaud it walks the C stack?
15:31 jonathan Right.
15:31 Whiteknight pmichaud: yes
15:32 pmichaud interesting.
15:32 Whiteknight you can see the (horrible) code for it in src/gc/system.c
15:32 Whiteknight I would like nothing more then to kill it in a fire, but it's there
15:32 jonathan Well, we kinda need to walk it, or we miss things.
15:32 pmichaud right, makes sense.
15:33 jonathan But somehow we're missing pos_args here, it seems. :-/
15:33 jonathan That or some other bug.
15:33 pmichaud it's not on the c stack.
15:33 Whiteknight jonathan: where is that code you mentioned?
15:33 Whiteknight perl6multisub.pmc?
15:33 jonathan src/pmc/perl6multisub.pmc
15:33 pmichaud well, I guess it must be, but it's not an argument.
15:33 jonathan pmichaud: Huh?
15:33 jonathan pmichaud: OK, but it's a local.
15:34 pmichaud right.
15:34 jonathan Those must be pushed on the stack at some point, right?
15:34 pmichaud yes, I think so.
15:34 jonathan Also
15:34 Whiteknight jonathan: pos_args here is a PMC**, the GC can't track those
15:34 jonathan At the point we crash, it has been passed as an argument to do_dispatch.
15:34 jonathan Whiteknight: OK, but notice that
15:35 jonathan a) Inside get_args it's on the stack as a direct PMC *
15:35 Whiteknight jonathan: yes, but the PMC is getting collected before the call to do_dispatch
15:35 jonathan Ah.
15:36 jonathan Looking at what else gets allocated
15:36 jonathan I see
15:36 jonathan PMC    * const arg_hash       = pmc_new(interp, enum_class_Hash);
15:36 jonathan The PMC right after it.
15:36 jonathan oh, if we're boxing, potentially various others too in fact.
15:37 jonathan Whiteknight: Maybe set a breakpoint at the end of get_args and see if we're collected at that point?
15:37 Whiteknight doing that right now...
15:40 pmichaud here's a thought:
15:40 pmichaud nm
15:44 Whiteknight okay, I put in a bunch of asserts, building now
15:44 pmichaud where is "get_all_candidates_with_cur_args"  called?
15:44 jonathan from p6invocation iirc
15:45 jonathan yes
15:45 jonathan line 76
15:45 jonathan All part of the fun interplay betwene the dispatchers. :-)
15:45 pmichaud ah, I see.
15:45 pmichaud The *.pmc code doesn't appear to be following the parrot coding style -- that was throwing me a bit
15:46 jonathan In what way?
15:46 jonathan Though it's out of the Parrot repo, so it doesn't have to.
15:46 jonathan It's not deliberately different though.
15:47 pmichaud in Parrot I'm used to seeing
15:47 pmichaud PMC *
15:47 pmichaud get_all_candidates_with_cur_args(...)
15:47 pmichaud instead of
15:47 Whiteknight what do the two different dispatchers do?
15:47 pmichaud PMC *get_all_candidates_with_cur_args
15:47 jonathan One does method dispatch, the other does multi dispatch.
15:48 jonathan pmichaud: Ah, OK.
15:48 Whiteknight ./perl6multisub.pmc:825: failed assertion 'pos_args->vtable != 0xdeadbeef'
15:48 pmichaud also, the p6invocation.pmc makes an extern reference to get_all_candidates.... but doesn't explicitly label it "extern" (and I missed the semi at the end)
15:48 pmichaud so it looked to me like it was re-defining the function somehow.
15:48 jonathan Ah, it wants extern?
15:48 pmichaud (when I read it from a grep)
15:49 Whiteknight I added the same assertion at the start of find_many_candidates_with_arg_list, and that one passed
15:49 Whiteknight and the assertion directly before do_dispatch fails
15:49 Whiteknight so somewhere inside find_many_candidates_with_arg_list, pos_args is getting collected
15:50 jonathan Which is very odd given
15:50 jonathan PMC *pos_args
15:50 jonathan is int he parameter list
15:50 jonathan And therefore surely on the stack?
15:50 pmichaud I was wondering if "return find_many_candidates_with_arg_list(...)"  was being optimized somehow such that *pos_args isn't on the stack.
15:50 pmichaud i.e., if gcc thinks it's a tailcall
15:51 Whiteknight I would hope so, unless the compiler did some creepy optimization magic
15:51 jonathan That'd be some really creepy magic.
15:51 Whiteknight that's why I dislike stackwalking GC stuff, because stackwalking + optimizing c compiler = horrible
15:52 pmichaud Whiteknight: what happens if you split the return statement into two statements?
15:52 pmichaud (ooc)
15:53 Whiteknight no idea, I'm running another test right now
15:53 jonathan Whiteknight: I know that
15:53 jonathan if (cache)
15:53 jonathan results = Parrot_mmd_cache_lookup_by_values(interp, cache, "", pos_args);
15:53 jonathan Certainly allocates a STRING.
15:53 Whiteknight (and these tests are painfully slow with the --gc-debug flag)
15:53 jonathan Also, if we run it, sort_candidates will allocate an absolute LOAD of stuff.
15:53 Whiteknight okay, pos_args is collected during this call:
15:53 Whiteknight candidates = sort_candidates(interp, unsorted, &proto);
15:53 jonathan So there's easily scope for allocation.
15:53 jonathan Ah
15:54 Whiteknight directly before, it's alive, directly after it's been collected
15:54 jonathan I'm just curious why it's not on the stack and anchored. :-/
15:54 jonathan But yes, sort_candidates will allocate PMCs for certain.
15:54 Whiteknight who knows? stack gremlins?
15:54 pmichaud I'd like to eliminate the (potential) tailcall and see what happens.
15:54 jonathan Worth a try for sure.
15:55 pmichaud (I agree it's a very long shot.)
15:56 jonathan Whiteknight: One tidbit though this still is no more clue to me: we do run PIR code during the course of sort_candidates.
15:57 Whiteknight that is interesting
15:57 Whiteknight Ahah! I think that might be the aswer
15:57 Whiteknight answer
15:57 jonathan We don't by any chance modify the stack top pointer?
15:58 Whiteknight when we recurse into a new runloop, I think we set a new lo_val_ptr on the stack, and don't mark anything on the stack above that
15:58 pmichaud I bet we do.
15:58 Whiteknight so anything that's not anchored when we recurse runloops falls off the face of the earth
15:58 jonathan oh arse
15:58 pmichaud that sounds like a serious problem.
15:58 jonathan That'd do it
15:58 jonathan That'd completely do it.
15:59 pmichaud given Parrot's design, I'm not sure that we can ever be certain that everything is anchored prior to recursing into a new runloop
16:00 jonathan No, me either.
16:00 Whiteknight we can tell parrot not to change the stacktop pointer when it recurses though
16:00 jonathan Aye.
16:00 jonathan I'm curious why we're setting it at that point.
16:00 Whiteknight because that sounds like stupid behavior, in hindsight
16:00 pmichaud doesn't that just translate to "don't change the stacktop pointer"?
16:00 jonathan I suspect it was a case of
16:00 Whiteknight I have to double-check that we are re-setting it, but I think we are
16:00 jonathan "we need to do it at some point"
16:01 jonathan And at one time, it was an OK place to do it
16:01 jonathan Like, when we didn't call back into PIR.
16:01 pmichaud well, it was likely OK.... right
16:01 jonathan From C.
16:01 jonathan This could easily explain various segfaults.
16:02 Whiteknight HA! I shut off the GC sweep at that point, pos_args is no longer getting prematurely swept, and now it segfaults later in the test
16:02 jonathan bwah
16:03 nopaste "Whiteknight" at 69.248.162.161 pasted "new segfault, backtrace for jonathan++ and pmichaud++" (48 lines) at http://nopaste.snit.ch/17111
16:03 flh joined #parrot
16:03 * Whiteknight is reminded of GSOC: fix one segfault and a new one just appears later
16:04 pmichaud well, "shut off GC sweep"  sounds like "workaround" and not "fix" to me
16:04 jonathan Oh, it's surely the same issue.
16:04 jonathan mmd_cache_key_from_values
16:04 jonathan That values pointer is also pos_args
16:04 pmichaud we can't keep shutting off the GC every time we might recurse
16:04 jonathan do_dispatch may also call into PIR
16:05 jonathan So almost certainly it's the same issue with recursion into PIR, and fixing that will clear this up.
16:05 pmichaud in particular, I don't think we can expect .pmc writers to know every possible situation in which they might recurse
16:05 jonathan aye
16:05 jonathan Well, Whiteknight++ maybe was just trying it to ensure it was that issue rather than proposing it as a fix.
16:06 pmichaud yes.
16:06 Whiteknight yeah, I was just proving that was the source of the issues. Looking for a more permanent solution now
16:06 pmichaud what's the purpose of lo_val_ptr ?
16:07 jonathan To make sure we don't walk too far down the stack
16:08 pmichaud I can't even find "lo_val_ptr" (with ack)
16:08 Andy Hey, you know what I'd like to get rid of?
16:09 Andy functions that take NULL PMCs that I assume are doing it only as a safety check
16:12 pmichaud ah, it's "lo_var_ptr"
16:12 Whiteknight lo_var_ptr
16:12 Whiteknight yes, sorry
16:16 Whiteknight okay, so I think I was mistaken. I don't think the stacktop is being changed on runloop recursions
16:16 pmichaud I agree.
16:17 pmichaud if it is, I can't find it.
16:17 Whiteknight ditto
16:19 Whiteknight but that doesn't change the fact that a PMC that is only anchored on the stack is disappearing after a recursion into a new runloop
16:19 Whiteknight whether it's the recursion that causes the problem or not is yet to be determined
16:19 pmichaud exactly.
16:21 pmichaud So I suspect something is wrong with the algorithm for finding PMCs on the stack
16:22 pmichaud either the algorithm itself, or where it's being told to search
16:22 jonathan It couldn't be at all anything to do with longjmp-ish stuff?
16:22 pmichaud I'd think that's another possibility.
16:23 pmichaud that what we think is a "stack" isn't really complete because of longjmp
16:24 Whiteknight that might be possible I suppose
16:24 pmichaud I'm not familiar enough with longjmp to say, though.
16:24 Whiteknight but I have a problem thinking that we're longjmping to a point on the stack above where pos_args is being used
16:24 pmichaud we might not be (more)
16:24 Whiteknight based on what little I know about how exception handling works
16:25 pmichaud we could be longjumping to a point on the stack below wehre pos_args is being used
16:25 pmichaud and for that reason the stack trace isn't getting to pos_args
16:25 jonathan I don't know enough about lngjmp stuff either.
16:25 pmichaud (I might have my above/below backwards, sorry if that's the case)
16:29 amuck joined #parrot
16:32 Whiteknight pmichaud: I think you might have been on to something with the longjmp stuff. testing now
16:40 Whiteknight nope, false alarm
16:41 Whiteknight this is a tricky nut to crack
16:44 dalek parrot: r39880 | fperrad++ | trunk (2 files):
16:44 dalek parrot: [codingstd] put config_h.in under control
16:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39880/
16:44 Andy seen mauke
16:44 purl mauke was last seen on #perl 15 hours, 45 minutes and 3 seconds ago, saying: source: http://www.datapacrat.com/Ar​t/Fiction/STORIES/SMALL.TXT
16:50 skids Huh.  I never thought about the implications of "stackless" stuff WRT debuggers.
16:53 Whiteknight stupid gdb question: how do I set a breakpoint on a function only if the parameter is a particular value?
16:53 * Whiteknight has to go dig out his gdb reference book
17:02 Whiteknight pos_args is definitely being collected inside Parrot_run_meth_fromc_args
17:02 Whiteknight the gc_debug runcore is collecting it
17:04 Whiteknight and the lo_var_ptr is the same in both places
17:19 AndyA joined #parrot
17:25 Whiteknight AHA! I think I've got it!
17:26 Whiteknight runops_gc_debug core calls Parrot_gc_mark_and_sweep(interp, 0);
17:26 jonathan What's the 0?
17:26 jonathan The problem?
17:26 purl In 1972 a crack commando unit was sent to prison for a crime thry didn't commit. These men promptly escaped from a maximum security stockade to the Los Angeles underground. Today, they survive as soldiers of fortune. If you have a problem, if no one else can help, and if you can find them, maybe you can hire... the A Team.
17:27 jonathan Yeah let's get the A Team to debug our GC!
17:27 Whiteknight notice that it doesnt call it with GC_TRACE_FULL, which would trace the stack
17:28 Whiteknight so the gc_debug runcore is not tracing the stack, so anything that's stack-only will get killed when we recurse into this runcore
17:28 Whiteknight so the gc_debug core creates new bugs that we wouldn't see otherwise
17:29 dukeleto joined #parrot
17:29 Whiteknight changing to the normal slow core, and the test completes without problem
17:29 Whiteknight even passes
17:31 Tene oh man, that's hilarious. :D
17:34 jonathan Damm!
17:37 pmichaud so.....
17:37 pmichaud you're saying that the other fix you did seems to have resolved the problem?
17:38 pmichaud (or at least moved it somewhere else?)
17:39 skids joined #parrot
17:45 bobke joined #parrot
18:14 Whiteknight spectest fails a lot fewer tests now
18:14 Whiteknight not zero though
18:19 davef joined #parrot
18:21 davef left #parrot
18:29 pmichaud well, there are some failing tests that aren't -G related
18:29 pmichaud afk, errands
18:31 Whiteknight that's a good sign, right? that the tests aren't -G related?
18:33 jonathan Yes.
18:33 david joined #parrot
18:34 david left #parrot
18:37 dalek parrot: r39881 | whiteknight++ | trunk/src (2 files):
18:37 dalek parrot: [gc] use mem_allocate_zeroed_typed instead of mem_allocate_typed + memset. Suggested to me by ... everybody who saw my r39879. fperrad++, pmichaud++, Infinoid++
18:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39881/
18:37 Whiteknight Well, I'm going to do my best W. and declare "mission accomplished"
18:40 nopaste "mikehh" at 90.209.206.211 pasted "codetest failure from make fulltest at r39880 (PATCH follows)" (32 lines) at http://nopaste.snit.ch/17113
18:40 mikehh codetest fails at r39880 - all others PASS - Ubuntu 9.04 amd64 - PATCH done - PASSes
18:40 dalek parrot: r39882 | whiteknight++ | trunk/src/runcore/cores.c:
18:40 dalek parrot: [gc] The gc_debug core doesn't trace the system stack between dispatches. This causes a problem when we recurse into a new runcore while there are PObjs in the previous runcore that are only located on the stack and not anchored anywhere else in the memory graph. Change this to run a GC_TRACE_FULL trace, to make sure we cover the stack. Sure it's slower, but we don't use gc_debug because of the blinding speed
18:40 nopaste "mikehh" at 90.209.206.211 pasted "PATCH for codetest failure at r39880" (13 lines) at http://nopaste.snit.ch/17114
18:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39882/
18:41 ttbot whiteknight: Parrot trunk/ r39881 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/45723.txt
18:41 Whiteknight wtf? what is ttbot?
18:42 Whiteknight mikehh: I think I already fixed that in r39881
18:42 Whiteknight mikehh++ though
18:43 jan joined #parrot
18:44 ttbot whiteknight: Parrot trunk/ r39882 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/45738.txt
18:45 mikehh Whiteknight: yes you removed the problem "sizeof"
18:46 Whiteknight ok
18:46 dalek parrot: r39883 | whiteknight++ | trunk/include/parrot/pmc.h:
18:46 dalek parrot: [gc] make headerizer to fix problems with gc_unregister_pmc which were introduced for some systems in r39881
18:46 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39883/
18:47 Whiteknight EAT THAT TTBOT!
18:54 skids heheh.  ttbot: "the compiler that stalks your ass"
18:56 Whiteknight who runs ttbot?
18:56 Whiteknight ttbot?
18:56 Whiteknight purl: you're worthless
18:56 purl Whiteknight: huh?
18:56 Whiteknight just the response I would expect from a worthless bot
19:11 mikehh All tests PASS (pre/post config, smolder, fulltest) at r39883 - Ubuntu 9.04 amd64
19:27 Infinoid what's a ttbot?
19:33 mberends my xchat says it's TapTinder bot, at the Brno University of Technology
19:37 mikehh more rakudo tests passing (4/5 real fails) t/spec/S04-declarations/constant.rakudo exits after 7 out of 20 with Null PMC access in type()
19:44 PacoLinux joined #parrot
19:45 Theory joined #parrot
20:29 Austin joined #parrot
20:32 david joined #parrot
21:03 bacek joined #parrot
21:10 klapperl left #parrot
21:10 bacek goo morning #parrot
21:10 bacek good of course
21:10 Austin oodgay orningmay, acekbay
21:11 bacek Austin: :)
21:11 mikehh not yet 1 hour + to go, but hi anyway
21:14 bacek Hooray! Whiteknight++
21:17 Austin ??
21:18 bacek Austin: GC fix.
21:20 Austin ??
21:21 Austin Ignore that last ??
21:21 Austin I hit uparrow by mistake.
21:38 Tene Hi Austin. :)
21:39 Austin Hello, Tene.
21:41 dalek parrot: r39884 | bacek++ | failed to fetch changeset:
21:41 dalek parrot: Bring brach up-to-date with trunk.
21:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39884/
21:46 bacek purl: TapTinder?
21:46 purl TapTinder is back, http://tt.perl6.cz/ .. need port watchdog to linux ... some test hang in r26917
21:46 bacek purl: ttbot is TapTinder bot. Owned by rj41
21:46 purl OK, bacek.
21:55 * Austin is grinding testcases for PCT
21:56 Austin Bleargh
22:09 dduncan joined #parrot
22:10 dduncan left #parrot
22:34 rg joined #parrot
22:58 Austin Double-bleargh. Undef != null.
23:03 Austin msg pmichaud Patrick, when a class (e.g., PCT::Node) uses P6object to extend Capture, printing an object of the class reports "Capture[0xb74b34a8]" instead of the name of the newly derived class. Is this a bug?
23:03 purl Message for pmichaud stored.
23:04 Austin msg pmichaud Patrick, when a class (e.g., PCT::Node) uses P6object to extend Capture, printing an object of the class reports "Capture[0xb74b34a8]" instead of the name of the newly derived class. Is this a bug?
23:04 purl Message for pmichaud stored.
23:04 Austin Man, I have to watch that alt-tab+up+enter. sigh
23:04 Austin Sorry, patrick.
23:15 Limbic_Region joined #parrot
23:16 pmichaud Austin: if it's a bug, it's not completely a bug in PCT
23:17 pmichaud it's true also for any class (P6object or not) that extends built-in PMC types
23:17 pmichaud for example, try it with Hash
23:18 nopaste "pmichaud" at 72.181.176.220 pasted "subclasses of PIR classes don't always stringify to subclass name (for Austin)" (11 lines) at http://nopaste.snit.ch/17116
23:30 dalek parrot: r39885 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
23:30 dalek parrot: [pmc] Don't use MULTIs in Hash... It was way too optimistic.
23:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39885/

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced