Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segementation fault after a ~500 regex compilations + matches #296

Closed
p6rt opened this issue Sep 4, 2008 · 10 comments
Closed

Segementation fault after a ~500 regex compilations + matches #296

p6rt opened this issue Sep 4, 2008 · 10 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Sep 4, 2008

Migrated from rt.perl.org#58578 (status was 'resolved')

Searchable as RT58578$

@p6rt
Copy link
Author

p6rt commented Sep 4, 2008

From @moritz

Rakudo r30754 segfaults while running some regexe tests.
How to reproduce​:

cd languages/perl6/t/spec/
vim t/spec/S05-mass/pge-tests.t # set variable $segfault_limit to 745
svn up -r 22156
cd ../..
../../parrot perl6.pbc t/spec/S05-mass/pge-tests.t

wait patiently until it dies. Adding -G doesn't remove that segfault.

Cheers,
Moritz

--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/

@p6rt
Copy link
Author

p6rt commented Sep 5, 2008

From @chromatic

On Thursday 04 September 2008 11​:40​:36 Moritz Lenz wrote​:

# New Ticket Created by Moritz Lenz
# Please include the string​: [perl #​58578]
# in the subject line of all future correspondence about this issue.
# <URL​: http://rt.perl.org/rt3/Ticket/Display.html?id=58578 >

Rakudo r30754 segfaults while running some regexe tests.
How to reproduce​:

cd languages/perl6/t/spec/
vim t/spec/S05-mass/pge-tests.t # set variable $segfault_limit to 745
svn up -r 22156
cd ../..
../../parrot perl6.pbc t/spec/S05-mass/pge-tests.t

wait patiently until it dies. Adding -G doesn't remove that segfault.

Run it through GDB, and it looks like Parrot runs out of stack space
recursivelyly throwing exceptions. If someone modifies Rakudo not to catch
the topmost exception, I bet we could track this down faster.

(I also modified the test file to skip the first 500+ tests, and I still get
weird segfaults here.)

Ah, I've seen this sort of thing before.

#​152 0xb7c484c1 in fail_if_type_exists (interp=0x804f040, name=0xb7285c48)
  at src/oo.c​:619
#​153 0xb7c48534 in Parrot_oo_register_type (interp=0x804f040, name=0xb7285c48)
  at src/oo.c​:649
#​154 0xb7de95da in init_class_from_hash (interp=0x804f040, self=0xb7285af8,
  info=0xb7285938) at ./src/pmc/class.pmc​:222
#​155 0xb7deb038 in Parrot_Class_init_pmc (interp=0x804f040, pmc=0xb7285af8,
  init_data=0xb7285c48) at ./src/pmc/class.pmc​:512
#​156 0xb7c53f01 in pmc_new_init (interp=0x804f040, base_type=49,
  init=0xb7285c48) at src/pmc.c​:368
#​157 0xb7bba048 in Parrot_newclass_p_p (cur_opcode=0xb7ab0b24,
  interp=0x804f040) at src/ops/object.ops​:249
#​158 0xb7c5490c in runops_slow_core (interp=0x804f040, pc=0xb7ab0b24)
  at src/runops_cores.c​:222
#​159 0xb7c15e49 in runops_int (interp=0x804f040, offset=3289)
---Type <return> to continue, or q <return> to quit---
  at src/interpreter.c​:937
#​160 0xb7c16723 in runops (interp=0x804f040, offs=3289) at src/inter_run.c​:101
#​161 0xb7c169ef in runops_args (interp=0x804f040, sub=0xb728d268,
  obj=0x80a7f50, meth_unused=0x0, sig=0xb7e884e8 "vPS",
  ap=0xbf82f8ac "@​��<\020n��L\b�\202���@​�004\b@​��<\020n�\024")
  at src/inter_run.c​:236
#​162 0xb7c16b3c in Parrot_runops_fromc_args (interp=0x804f040, sub=0xb728d268,
  sig=0xb7e884e8 "vPS") at src/inter_run.c​:300
#​163 0xb7c026aa in Parrot_ex_throw_from_c (interp=0x804f040,
  exception=0xb728ce40) at src/exceptions.c​:292
#​164 0xb7c0277e in Parrot_ex_throw_from_c_args (interp=0x804f040,
  ret_addr=0x0, exitcode=20,
  format=0xb7e8b644 "Class %Ss already registered!\n")
  at src/exceptions.c​:339
#​165 0xb7c484c1 in fail_if_type_exists (interp=0x804f040, name=0xb728d134)
  at src/oo.c​:619
#​166 0xb7c48534 in Parrot_oo_register_type (interp=0x804f040, name=0xb728d134)
  at src/oo.c​:649
#​167 0xb7de95da in init_class_from_hash (interp=0x804f040, self=0xb728d08c,
  info=0xb728ce94) at ./src/pmc/class.pmc​:222
#​168 0xb7deb038 in Parrot_Class_init_pmc (interp=0x804f040, pmc=0xb728d08c,
  init_data=0xb728d134) at ./src/pmc/class.pmc​:512
#​169 0xb7c53f01 in pmc_new_init (interp=0x804f040, base_type=49,
  init=0xb728d134) at src/pmc.c​:368
#​170 0xb7bba048 in Parrot_newclass_p_p (cur_opcode=0xb7ab0b24,
  interp=0x804f040) at src/ops/object.ops​:249

This co-recurses for a while, and then Parrot runs out of contexts, and *that*
exception loops for a while. An exception handler around here is wonky in
that it causes an attempt to register a new type. Fun.

-- c

1 similar comment
@p6rt
Copy link
Author

p6rt commented Sep 5, 2008

From @chromatic

On Thursday 04 September 2008 11​:40​:36 Moritz Lenz wrote​:

# New Ticket Created by Moritz Lenz
# Please include the string​: [perl #​58578]
# in the subject line of all future correspondence about this issue.
# <URL​: http://rt.perl.org/rt3/Ticket/Display.html?id=58578 >

Rakudo r30754 segfaults while running some regexe tests.
How to reproduce​:

cd languages/perl6/t/spec/
vim t/spec/S05-mass/pge-tests.t # set variable $segfault_limit to 745
svn up -r 22156
cd ../..
../../parrot perl6.pbc t/spec/S05-mass/pge-tests.t

wait patiently until it dies. Adding -G doesn't remove that segfault.

Run it through GDB, and it looks like Parrot runs out of stack space
recursivelyly throwing exceptions. If someone modifies Rakudo not to catch
the topmost exception, I bet we could track this down faster.

(I also modified the test file to skip the first 500+ tests, and I still get
weird segfaults here.)

Ah, I've seen this sort of thing before.

#​152 0xb7c484c1 in fail_if_type_exists (interp=0x804f040, name=0xb7285c48)
  at src/oo.c​:619
#​153 0xb7c48534 in Parrot_oo_register_type (interp=0x804f040, name=0xb7285c48)
  at src/oo.c​:649
#​154 0xb7de95da in init_class_from_hash (interp=0x804f040, self=0xb7285af8,
  info=0xb7285938) at ./src/pmc/class.pmc​:222
#​155 0xb7deb038 in Parrot_Class_init_pmc (interp=0x804f040, pmc=0xb7285af8,
  init_data=0xb7285c48) at ./src/pmc/class.pmc​:512
#​156 0xb7c53f01 in pmc_new_init (interp=0x804f040, base_type=49,
  init=0xb7285c48) at src/pmc.c​:368
#​157 0xb7bba048 in Parrot_newclass_p_p (cur_opcode=0xb7ab0b24,
  interp=0x804f040) at src/ops/object.ops​:249
#​158 0xb7c5490c in runops_slow_core (interp=0x804f040, pc=0xb7ab0b24)
  at src/runops_cores.c​:222
#​159 0xb7c15e49 in runops_int (interp=0x804f040, offset=3289)
---Type <return> to continue, or q <return> to quit---
  at src/interpreter.c​:937
#​160 0xb7c16723 in runops (interp=0x804f040, offs=3289) at src/inter_run.c​:101
#​161 0xb7c169ef in runops_args (interp=0x804f040, sub=0xb728d268,
  obj=0x80a7f50, meth_unused=0x0, sig=0xb7e884e8 "vPS",
  ap=0xbf82f8ac "@​��<\020n��L\b�\202���@​�004\b@​��<\020n�\024")
  at src/inter_run.c​:236
#​162 0xb7c16b3c in Parrot_runops_fromc_args (interp=0x804f040, sub=0xb728d268,
  sig=0xb7e884e8 "vPS") at src/inter_run.c​:300
#​163 0xb7c026aa in Parrot_ex_throw_from_c (interp=0x804f040,
  exception=0xb728ce40) at src/exceptions.c​:292
#​164 0xb7c0277e in Parrot_ex_throw_from_c_args (interp=0x804f040,
  ret_addr=0x0, exitcode=20,
  format=0xb7e8b644 "Class %Ss already registered!\n")
  at src/exceptions.c​:339
#​165 0xb7c484c1 in fail_if_type_exists (interp=0x804f040, name=0xb728d134)
  at src/oo.c​:619
#​166 0xb7c48534 in Parrot_oo_register_type (interp=0x804f040, name=0xb728d134)
  at src/oo.c​:649
#​167 0xb7de95da in init_class_from_hash (interp=0x804f040, self=0xb728d08c,
  info=0xb728ce94) at ./src/pmc/class.pmc​:222
#​168 0xb7deb038 in Parrot_Class_init_pmc (interp=0x804f040, pmc=0xb728d08c,
  init_data=0xb728d134) at ./src/pmc/class.pmc​:512
#​169 0xb7c53f01 in pmc_new_init (interp=0x804f040, base_type=49,
  init=0xb728d134) at src/pmc.c​:368
#​170 0xb7bba048 in Parrot_newclass_p_p (cur_opcode=0xb7ab0b24,
  interp=0x804f040) at src/ops/object.ops​:249

This co-recurses for a while, and then Parrot runs out of contexts, and *that*
exception loops for a while. An exception handler around here is wonky in
that it causes an attempt to register a new type. Fun.

-- c

@p6rt
Copy link
Author

p6rt commented Sep 5, 2008

The RT System itself - Status changed from 'new' to 'open'

1 similar comment
@p6rt
Copy link
Author

p6rt commented Sep 5, 2008

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Sep 5, 2008

From @chromatic

On Thursday 04 September 2008 17​:43​:55 chromatic wrote​:

Run it through GDB, and it looks like Parrot runs out of stack space
recursively throwing exceptions. If someone modifies Rakudo not to catch
the topmost exception, I bet we could track this down faster.

... and here's what I think the problem might be. At least this seems to fix
it for me.

Just don't ask me *why* things to pear-shaped, unless this really is a silly
off-by-one error I haven't traced on paper yet to prove.

-- c

@p6rt
Copy link
Author

p6rt commented Sep 5, 2008

From @chromatic

rakudo_rx_seggie.patch
=== languages/perl6/src/builtins/guts.pir
==================================================================
--- languages/perl6/src/builtins/guts.pir	(revision 30796)
+++ languages/perl6/src/builtins/guts.pir	(local)
@@ -91,7 +91,7 @@
     push_eh outer_err
     null value
   loop:
-    unless max >= min goto done
+    unless max > min goto done
     $P0 = getinterp
     lexpad = $P0['outer', depth]
     unless lexpad goto next

@p6rt
Copy link
Author

p6rt commented Nov 7, 2008

From @pmichaud

Looks to me like this bug was resolved around r30772. If anyone else
encounters the bug, re-open a ticket.

Thanks!

Pm

1 similar comment
@p6rt
Copy link
Author

p6rt commented Nov 7, 2008

From @pmichaud

Looks to me like this bug was resolved around r30772. If anyone else
encounters the bug, re-open a ticket.

Thanks!

Pm

@p6rt
Copy link
Author

p6rt commented Nov 7, 2008

@pmichaud - Status changed from 'open' to 'resolved'

@p6rt p6rt closed this as completed Nov 7, 2008
@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant