Rather badly, actually. All the tests that involve parrot currently segfault in the NCI mark routine. At least on OS X, I'm not sure about other platforms. -- Dan
--------------------------------------"it's like this"------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
Dan Sugalski wrote: > Rather badly, actually. All the tests that involve parrot currently > segfault in the NCI mark routine. At least on OS X, I'm not sure about > other platforms.
Not on i386/Linux, anyway ...
Could be a slightly wrong init sequence, which I did introduce and have hopefully fixed now.
When the commit cures the problem I have one addition, to (hopefully) provoke such errors with --gc-debug.
Dan Sugalski wrote: > Rather badly, actually. All the tests that involve parrot currently > segfault in the NCI mark routine. At least on OS X, I'm not sure about > other platforms.
Some questions WRT tinderboxen: - above error seems currently not to be covered - which machines are when reported/online (now only ~5) - could we (people that wants to) have a *short* daily mail report like:
It appears to be the same thing for tcc and lcc on linux. The nearest I can tell, the value stuffed into struct_val in Parrot_NCI_set_string_keyed is somehow not a valid PObj- dereferencing its "obj" member seems to blow things up.
It stomps all over the stack somehow, and I don't have much debugger mojo.
Plus, building with "-g" makes the problem go away. Bah.
--Josh
At 14:09 on 01/20/2003 EST, Dan Sugalski <d...@sidhe.org> wrote:
> Rather badly, actually. All the tests that involve parrot currently > segfault in the NCI mark routine. At least on OS X, I'm not sure > about other platforms. > -- > Dan
> --------------------------------------"it's like this"------------------- > Dan Sugalski even samurai > d...@sidhe.org have teddy bears and even > teddy bears get drunk
On Mon, Jan 20, 2003 at 02:09:10PM -0500, Dan Sugalski wrote: > Rather badly, actually. All the tests that involve parrot currently > segfault in the NCI mark routine. At least on OS X, I'm not sure > about other platforms.
5.8.0/Sparc64/OpenBSD is also rather unhappy.
I'm getting the following core dumps: intlist_1.core intlist_3.core list_1.core parrot.core sprintf_2.core intlist_2.core intlist_4.core list_2.core sprintf_1.core
parrot.core is the only one that seems to be having problems with Parrot_NCI_mark, however.
% gdb -c parrot.core parrot GNU gdb 4.16.1 This GDB was configured as "sparc64-unknown-openbsd3.1" Core was generated by `parrot'. Program terminated with signal 10, Bus error. #0 0x1a8638 in pobject_lives () (gdb) bt #0 0x1a8638 in pobject_lives () #1 0x1bcc78 in Parrot_NCI_mark () #2 0x1a8b88 in trace_active_PMCs () #3 0x1a9340 in Parrot_do_dod_run () #4 0x1a72c0 in more_traceable_objects () #5 0x1a73cc in get_free_object () #6 0x1a7a1c in get_free_buffer () #7 0x1a7f3c in new_bufferlike_header () #8 0x164354 in list_new () #9 0x1b2190 in Parrot_Array_init () #10 0x1663b0 in setup_argv () #11 0x166640 in Parrot_runcode () #12 0x1cdf98 in main () #13 0x11332c in ___start ()
blair christensen wrote: > On Mon, Jan 20, 2003 at 02:09:10PM -0500, Dan Sugalski wrote:
>>Rather badly, actually. All the tests that involve parrot currently >>segfault in the NCI mark routine. At least on OS X, I'm not sure >>about other platforms. > (gdb) bt > #0 0x1a8638 in pobject_lives () > #1 0x1bcc78 in Parrot_NCI_mark ()
On Tue, Jan 21, 2003 at 01:53:26PM +0100, Leopold Toetsch wrote: > blair christensen wrote:
> >On Mon, Jan 20, 2003 at 02:09:10PM -0500, Dan Sugalski wrote:
> >>Rather badly, actually. All the tests that involve parrot currently > >>segfault in the NCI mark routine. At least on OS X, I'm not sure > >>about other platforms.
> >(gdb) bt > >#0 0x1a8638 in pobject_lives () > >#1 0x1bcc78 in Parrot_NCI_mark ()
> Is this with my patch (in CVS) already applied?
Yes.
I just did a realclean, cvs up, configure, make, and make test.
Lots of core files and as the last tinderbox report for this box shows [0], a lot of failed tests. Parrot has never been completely happy on this box but it seems to have taken a turn for the worse.
Here's another data-point, for Linux/x86: with a fresh check-out, parrot is passing all of its tests, but most of the imcc tests are failing. Specifically, I get:
Closer examination suggests that all of these tests are failing because imcc is sgefaulting; a representative backtrace is:
Program received signal SIGSEGV, Segmentation fault. 0x080dfb0a in pobject_lives () (gdb) bt #0 0x080dfb0a in pobject_lives () #1 0x080ec252 in Parrot_NCI_mark () #2 0x080dfe94 in trace_active_PMCs () #3 0x080e03ac in Parrot_do_dod_run () #4 0x080e4cdd in more_traceable_objects () #5 0x080e4d7c in get_free_object () #6 0x080df260 in get_free_buffer () #7 0x080df61a in new_bufferlike_header () #8 0x080b60e3 in list_new () #9 0x080e51ff in Parrot_Array_init () #10 0x080b76ae in setup_argv () #11 0x080b7834 in Parrot_runcode () #12 0x0805693a in main ()
...which looks to be related to the problem people are encountering on the other platforms.
>>>#0 0x1a8638 in pobject_lives () >>>#1 0x1bcc78 in Parrot_NCI_mark ()
I dunno yet, why mark is called with an uninitialized struct_val. The mark function should only be called, if the corresponding flag is set.
For a first check, what's going on, I added init() again, which clears struct_val.
I still don't understand, why NCI's mark is called. These objects are only present in nci and (derived in) eval tests (and one pmc test or so). Wrong object numbering or such, which "make realclean" (the dependencies in the first place but, ...) should cope with.
