I've just started trying to experiment with parrot, and I keep getting segmentation faults, eg when running the following one-liner:
set I0, 7
I'm using gcc 2.95.4 on linux, and it says all the tests are passing when I run make test.
gdb gives the following:
---------------
[New Thread 16384 (LWP 16833)] [New Thread 32769 (LWP 16834)] [New Thread 16386 (LWP 16835)]
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 16833)] 0x0807f9ec in runops_slow_core (interpreter=0x823bc90, pc=0x827ed34) at src/runops_cores.c:116 116 (pc = ((interpreter->op_func_table)[*pc])(pc,interpreter));
-------------
If I change the input file to
set I0, 7 set I0, 7
then it appears to run fine (well, I don't get any unexpected output...). Any odd number of these lines seems to cause the problem.
Also, if I use the -o option to save the bytecode, and then run that, I don't get any problems.
Am I doing something wrong or is it a problem with parrot?
I also noticed what seems to be inconsistent behaviour with regard to supplying options to parrot.
parrot -r -o file file.pasm and parrot -o file -r file.pasm
do different things, as the code that handles the -o option overwrites the -r option:
case 'r': ++run_pbc; break;
... case 'o': run_pbc = 0; output = str_dup(opt.opt_arg); break;
I assume this isn't deliberate, but I'm not sure what the desired behaviour is.
Chris.