[perl #44393] something funny in dod/gc blocking macros

2008-05-06 Thread Will Coleda via RT
On Fri Aug 03 13:43:42 2007, [EMAIL PROTECTED] wrote:
 On Friday 03 August 2007 13:29:53 Jerry Gay wrote:
 
  i'm having trouble on x86_64. when running a 32bit parrot, i get
  occasional deadlock at the OS level, after Parrot_exit. when running a
  64bit parrot, it segfaults within Parrot_exit, while running the exit
  handlers. if i run with -G, no segfault.
 
 Bram Geron's patches in RT #44363 and RT #44351 look reasonable to me.  I 
 think they might work for you.
 
 -- c
 

Jerry, can you try out these patches and see if we can close the ticket?

Thanks.





[perl #44393] something funny in dod/gc blocking macros

2007-08-03 Thread via RT
# New Ticket Created by  Jerry Gay 
# Please include the string:  [perl #44393]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44393 


i'm having trouble on x86_64. when running a 32bit parrot, i get
occasional deadlock at the OS level, after Parrot_exit. when running a
64bit parrot, it segfaults within Parrot_exit, while running the exit
handlers. if i run with -G, no segfault.

a comment in the source notes that disabling dod/gc may be a good
thing to do, since gc during interpreter teardown could lead to Bad
Things. sounds like that's a valid note, and addressing it will fix my
problems.

so, i try a patch:

===
Index: src/exit.c
===
--- src/exit.c  (revision 20461)
+++ src/exit.c  (working copy)
@@ -70,6 +70,9 @@
  * and: interp-exit_handler_list is gone, after the last exit handler
  *  (Parrot_really_destroy) has run
  */
+Parrot_block_DOD(interp);
+Parrot_block_GC(interp);
+
 handler_node_t *node = interp-exit_handler_list;
 while (node) {
 handler_node_t * const next = node-next;

===

but that gives me compile errors:

===
src\exit.c
src\exit.c(76) : error C2275: 'handler_node_t' : illegal use of this type as an
expression
c:\usr\local\parrot\trunk\include\parrot/exit.h(25) : see declaration of
 'handler_node_t'
src\exit.c(76) : error C2065: 'node' : undeclared identifier
src\exit.c(78) : error C2223: left of '-next' must point to struct/union
src\exit.c(80) : error C2223: left of '-function' must point to struct/union
src\exit.c(80) : error C2223: left of '-arg' must point to struct/union
src\exit.c(81) : warning C4022: 'mem_sys_free' : pointer mismatch for actual par
ameter 1
src\exit.c(82) : warning C4047: '=' : 'int' differs in levels of indirection fro
m 'handler_node_t *const '
===

huh? something must be funny in these macros. a naive workaround:

===
Index: src/exit.c
===
--- src/exit.c  (revision 20461)
+++ src/exit.c  (working copy)
@@ -70,6 +70,10 @@
  * and: interp-exit_handler_list is gone, after the last exit handler
  *  (Parrot_really_destroy) has run
  */
+Parrot_block_DOD(interp);
+Parrot_block_GC(interp);
+
+{
 handler_node_t *node = interp-exit_handler_list;
 while (node) {
 handler_node_t * const next = node-next;
@@ -78,7 +82,7 @@
 mem_sys_free(node);
 node = next;
 }
-
+}
 exit(status);
 }

===

compiles without error.

what's going on here? i have i feeling i'm close to fixing this
annoying bug, but now i've got to dive into two or three levels of
hate, and i really want to start my weekend.

so, that's what i'm going to do. feel free to beat me to fixing this
before i pick up on it again next week, please!
~jerry


[perl #44393] something funny in dod/gc blocking macros

2007-08-03 Thread Jerry Gay via RT
hi, i'm a blockhead. ron reminded me that i'm not following C89, since
node was not defined at the top of a block. duh.

anyway, this doesn't seem to fix the problem. rats. i must misunderstand
the comment, because i find it hard to believe that adding these few
lines of code is enough to address a whole paragraph of comments.

your input is most welcome.
~jerry


Re: [perl #44393] something funny in dod/gc blocking macros

2007-08-03 Thread chromatic
On Friday 03 August 2007 13:29:53 Jerry Gay wrote:

 i'm having trouble on x86_64. when running a 32bit parrot, i get
 occasional deadlock at the OS level, after Parrot_exit. when running a
 64bit parrot, it segfaults within Parrot_exit, while running the exit
 handlers. if i run with -G, no segfault.

Bram Geron's patches in RT #44363 and RT #44351 look reasonable to me.  I 
think they might work for you.

-- c