Strangeness with '.sub' in macros
Bernhard Schmalhofer
I have been playing around with 'libpcre' for Parrot m4.
For some reason I couldn't compile two regular expressions in the same
PIR script.
I created a sample C program and that worked like it should.
It looks like the error has nothing to do with 'libpcre'. So I boiled down
my code to a small test script.
When a macro contains a '.sub' call, and that macro is used twice, then I get
a 'memory error'.
bernhard@linux:~/devel/Parrot/parrot/languages/m4> ../../parrot
t/regex/macro_used_twice.imc
Speicherzugriffsfehler
Could sombody test the attached script on another machine?
I'm working here on a Linux laptop:
bernhard@linux:~/devel/Parrot/parrot> uname -a
Linux linux 2.4.20-4GB-athlon #1 Mon Mar 17 17:56:47 UTC 2003 i686 unknown
unknown GNU/Linux
How can I tell 'parrot' to dump a core file?
CU, Bernhard
Harry Jackson
> Hi,
>
> Could sombody test the attached script on another machine?
> I'm working here on a Linux laptop:
I am geting a seg fault. Its fine when the second call is commented out.
I am not sure if any of the following is any use to you.
The follwoing PASM was part generated from your IMC, I added the bits
between "###". This calls the sub twice I am not sure if it is any use
to you. Please see some output from GDB at the end.
_main:
set P16, P1
newsub P16, 45, _dummy
@pcc_sub_call_2:
set I5, 1
set P0, P16
set I0, 1
set I1, 0
set I2, 0
set I3, 0
savetop
invokecc
restoretop
###
set I5, 2
set I0, 1
set I1, 0
set I2, 0
set I3, 0
savetop
invokecc
restoretop
###
end
_dummy:
print "dummy was called with: "
print I5
print "\n"
@pcc_sub_ret_25:
set I0, 1
set I1, 0
set I2, 0
set I3, 0
set I4, 0
invoke P1
[parrot@cpc5-lutn1-6-0-cust175 pbin]$ gdb parrot
GNU gdb Red Hat Linux (5.1-1)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) b runops_jit
Breakpoint 1 at 0x8075236: file src/interpreter.c, line 422.
(gdb) run -j -d test.pbc
Starting program: /home/parrot/bin/parrot -j -d test.pbc
[New Thread 1024 (LWP 17090)]
[New Thread 2049 (LWP 17091)]
[New Thread 1026 (LWP 17092)]
Address of base segment is (nil)
Address of base segment is (nil)
*** Parrot VM: JIT core ***
*** Parrot VM: Setting up ARGV array in P5. Current argc: 1 ***
0: test.pbc
[Switching to Thread 1024 (LWP 17090)]
Breakpoint 1, runops_jit (interpreter=0x8214a08, pc=0x400180d0) at
src/interpreter.c:422
422 jit_f jit_code = (jit_f) D2FPTR(init_jit(interpreter, pc));
(gdb) n
423 (jit_code) (interpreter, pc);
(gdb) n
Address of base segment is 0x400180d0
dummy was called with: 1
425 return NULL;
(gdb) n
426 }
(gdb) n
runops_int (interpreter=0x8214a08, offset=0) at src/interpreter.c:633
633 interpreter->lo_var_ptr = old_lo_var_ptr;
(gdb) n
634 if ((interpreter->resume_flag & RESUME_RESTART) &&
(gdb) n
553 while (interpreter->resume_flag & RESUME_RESTART) {
(gdb) n
638 }
(gdb) n
runops_ex (interpreter=0x8214a08, offset=0) at src/interpreter.c:652
652 if (interpreter->resume_flag & RESUME_ISJ) {
(gdb) n
679 }
(gdb) n
runops (interpreter=0x8214a08, offset=0) at src/interpreter.c:709
709 }
(gdb) n
Parrot_runcode (interpreter=0x8214a08, argc=1, argv=0xbffff980) at
src/embed.c:514
514 }
(gdb) n
main (argc=1, argv=0xbffff980) at imcc/main.c:551
551 Parrot_destroy(interpreter);
(gdb) n
552 if (output)
(gdb) n
554 mem_sys_free(interpreter->imc_info);
(gdb) n
555 Parrot_exit(0);
(gdb) n
*** Parrot VM: Dumping GC info ***
Total memory allocated = 139264
DOD runs = 0
Collect runs = 0
Collect memory = 0
Active PMCs = 1024
Active buffers = 6144
Total PMCs = 1024
Total buffers = 6144
Header allocations since last collect = 7
Memory allocations since last collect = 1
Program exited normally.
(gdb)
Harry Jackson
Melvin Smith
>Hi,
>
>I have been playing around with 'libpcre' for Parrot m4.
>For some reason I couldn't compile two regular expressions in the same
>PIR script.
>I created a sample C program and that worked like it should.
>
>It looks like the error has nothing to do with 'libpcre'. So I boiled down
>my code to a small test script.
>When a macro contains a '.sub' call, and that macro is used twice, then I get
>a 'memory error'.
>
>bernhard@linux:~/devel/Parrot/parrot/languages/m4> ../../parrot
>t/regex/macro_used_twice.imc
>Speicherzugriffsfehler
>
>Could sombody test the attached script on another machine?
>I'm working here on a Linux laptop:
Two answers here.
1) We probably have a bug in macro expansion
2) Dan has declared that macros are coming out of IMCC. (Mainly because I
told him
I don't want them and they make the lexer more complicated than I want it
to be.. and..
macros are less useful for compilers than people hand-writing IMC code)
I prefer macros to be a part of a preprocessor tool external to the builtin
IMC language.
If enough people really have strong opinions on macros, now is the time to
voice it, because
otherwise I'm removing them.
-Melvin
Leopold Toetsch
> When a macro contains a '.sub' call, and that macro is used twice, then I get
> a 'memory error'.
Confirmed. The segfault is in expand_pcc_sub_call(), the "sub" SymReg is
NULL on the second expansion.
> How can I tell 'parrot' to dump a core file?
Tell your OS to dump core :)
$ man bash
/ulimit
$ ulimit -c 20000
> CU, Bernhard
leo