Menu
▾
▴
#926 segmentation fault in the interpreter
A particular program sometimes core dumps. I shall add attachments when I see this in the tracker.
Linux bigserv 2.6.33.5-124.fc13.x86_64 #1 SMP Fri Jun 11 09:38:12 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
Core was generated by `rexx lxenum rexx.l'.
Program terminated with signal 11, Segmentation fault.
0 RoutineClass::restore (inData=0x7fffc4d8ef40, name=0x7f03d7c0ea90) at interpreter/classes/RoutineClass.cpp:799
799 if (data[0] == '#' && data[1] == '!')
(gdb) print data
$1 = 0x0
(gdb) where
0 RoutineClass::restore (inData=0x7fffc4d8ef40, name=0x7f03d7c0ea90) at interpreter/classes/RoutineClass.cpp:799
1 0x00000034254d5c1a in RexxActivation::getMacroCode (macroName=0x7f03d7c0ea90) at interpreter/execution/RexxActivation.cpp:2693
2 0x00000034254d5e80 in RexxActivation::callMacroSpaceFunction (this=0x7f03d7c00f00, target=0x7f03d7c0ea90, _arguments=0x7f03d73e58a0,
_argcount=1, calltype=0x7f03d8f38920, order=1, _result=...) at interpreter/execution/RexxActivation.cpp:2531
3 0x00000034255217cc in SystemInterpreter::invokeExternalFunction (activation=0x7fffc4d8ef40, activity=<value optimized="" out="">,
target=0x7f03d7c0ea90, arguments=0x7f03d73e58a0, argcount=1, calltype=0x7f03d8f38920, result=...) at interpreter/platform/unix/ExternalFunctions.cpp:338
4 0x00000034254d5dad in RexxActivation::externalCall (this=0x7f03d7c00f00, target=0x7f03d7c0ea90, _argcount=1, _stack=<value optimized="" out="">,
calltype=0x7f03d8f38920, resultObj=...) at interpreter/execution/RexxActivation.cpp:2598
5 0x000000342550521f in RexxInstructionCall::execute (this=0x7f03d7c0eb70, context=0x7f03d7c00f00, stack=0x7f03d7c01048)
at interpreter/instructions/CallInstruction.cpp:274
6 0x00000034254d7fad in RexxActivation::run (this=0x7f03d7c00f00, _receiver=<value optimized="" out="">, msgname=<value optimized="" out="">,
_arglist=0x3424409410, _argcount=0, start=0x11c1, resultObj=...) at interpreter/execution/RexxActivation.cpp:517
7 0x00000034254dcfac in RexxCode::call (this=<value optimized="" out="">, activity=0x7f03d7c079e0, routine=0x7f03d7c0ad40, msgname=0x7f03d8f384a0,
argPtr=0x7f03d7c0a770, argcount=1, calltype=0x7f03d8e27da0, environment=0x7f03d7c05ac0, context=16, result=...) at interpreter/execution/RexxCode.cpp:115
8 0x00000034254b6a22 in RoutineClass::runProgram (this=<value optimized="" out="">, activity=0x7f03d7c0ea90, calltype=<value optimized="" out="">,
environment=<value optimized out>, arguments=0x0, argCount=4545, result=...) at interpreter/classes/RoutineClass.cpp:305
9 0x00000034254fa7ed in RexxStartDispatcher::run (this=0x7fffc4d8f330) at interpreter/concurrency/RexxStartDispatcher.cpp:138
10 0x00000034254de474 in RexxNativeActivation::run (this=0x7f03d7c0a4f0, dispatcher=...) at interpreter/execution/RexxNativeActivation.cpp:1532
11 0x00000034254f9bf8 in RexxActivity::run (this=0x7f03d7c079e0, target=...) at interpreter/concurrency/RexxActivity.cpp:2944
12 0x00000034254f4984 in ActivityDispatcher::invoke (this=0x7fffc4d8f330, exits=<value optimized="" out="">, env=<value optimized="" out="">)
at interpreter/concurrency/ActivityDispatcher.cpp:121
13 0x00000034254cbf9d in RexxStart (argcount=1, arglist=0x7fffc4d8f460, programname=0x7fffc4d9373e "lxenum", instore=0x0, envname=0x400c84 "bash",
calltype=0, exits=0x0, retcode=0x7fffc4d8f47e, result=0x0) at interpreter/api/InterpreterAPI.cpp:163
14 0x0000000000400b3e in main (argc=3, argv=<value optimized="" out="">) at utilities/rexx/platform/unix/rexx.cpp:169
(gdb) qq
Discussion
Anonymous
Input data
Failing program
Looks like the dump is too large for the tracker. Send me mail if you wish me to print variables or do other things with gdb.
-rw------- 1 john staff 25858048 Aug 11 15:58 core-rexx-4545-1281535138
John, thanks for opening this bug and providing a test program.
Due to our limited resources it is hard to always address bugs promptly, but providing a test program sure helps a lot.
John,
Looks like this is on Fedora Core 13, correct? Do you remember which rpm package you used to install? Or did you build from source? Thanks.
Note that the error probably occurs less than 10% of the times. From the compares in the failing statement, I'd think it is trying to skip the hash-bang first record of the file. The program is run from a makefile, not that it should make any difference. There is a much larger rexx program in my build process as well and I don't think I've seen that fail.
The program has run for ages on fedora 6.
Sorry about the package. I had appended this in an earlier attempt that died on the dump size.
I installed oorexx with yum. Looks like "they" didn't update the package for Fedora 13. The system is a new build; there are no trace of the old system.
oorexx.x86_64 4.0.0-2.4801.fc12 @fedoraoorexx.x86_64 4.0.0-2.4801.fc12 @fedora
And just in case you got interested in the data file, it is not the final parser. I'm adding exclusive start states in to cope with various context sensitive parts of the language.
Hi John,
I'm not sure I follow this, (sorry a lot of times I don't seem to grasp what people are trying to tell me.)
"I installed oorexx with yum. Looks like "they" didn't update the package
for Fedora 13. The system is a new build; there are no trace of the old
system."
You say the system is a new build, but are you still using the oorexx installed through yum?
If so, would you please install one of our official builds downloaded from SourceForge, I would get 4.0.1 as there are a number of bug fixes in that release. (But probably none related to your bug.)
We've seen problems before in rpms built by third parties that didn't exist in the rpms we released from SourceForge.
Be sure you completely remove the old package before installing the one from SourceForge.
My bad. I'm no doubt bigoted by the many branches of unix now being put forward.
I meant that the system I'm using is physically new parts and also completely new install of all software. I got oorexx from the Fedora package site (wherever yum downloads from). No chance of old stuff in this system.
When it left IBM, the interpreter was written in ANSI C, at least the bits our friends in Sindelfingen let me see to help them understand the pipe problem, but when I looked into the resurfaced pipe problem recently I saw that the library routine that does lines() is now c++ and the traceback of the current problem also indicates c++. So it looks like the interpreter was rewritten in c++ over the last few years.
I think I'd rather stay with the c version. Can I download the source for that from anywhere now?
You can download the source code, and build yourself, but ooRexx is written in C++.
In early versions of ooRexx, most of the extensions were still written C. I'm not a100% sure since I didn't go look it up, but I believe the interpreter code has been C++ since we inherited it from IBM.
The reason I suggested you install from a package on SourceForge is that the packages built by Fedora have been known to have problems in the past.
It take back the comment that the interpreter fails only in a particular program.
Here it fails in the same way, but in a different and much larger program.
The only external function called by this particular program is SysGetFileDateTime.
Btw, all my programs are REXX classic.
Program terminated with signal 11, Segmentation fault.
0 RoutineClass::restore (inData=0x7fff6e2c2f50, name=0x7f2bf14e0220) at interpreter/classes/RoutineClass.cpp:799
799 if (data[0] == '#' && data[1] == '!')
(gdb) where
0 RoutineClass::restore (inData=0x7fff6e2c2f50, name=0x7f2bf14e0220) at interpreter/classes/RoutineClass.cpp:799
1 0x00000034254d5c1a in RexxActivation::getMacroCode (macroName=0x7f2bf14e0220) at interpreter/execution/RexxActivation.cpp:2693
2 0x00000034254d5e80 in RexxActivation::callMacroSpaceFunction (this=0x7f2bf14c7f00, target=0x7f2bf14e0220, _arguments=0x7f2bf0cac8a8, _argcount=2,
3 0x00000034255217cc in SystemInterpreter::invokeExternalFunction (activation=0x7fff6e2c2f50, activity=<value optimized="" out="">, target=0x7f2bf14e0220,
4 0x00000034254d5dad in RexxActivation::externalCall (this=0x7f2bf14c7f00, target=0x7f2bf14e0220, _argcount=2, _stack=<value optimized="" out="">,
5 0x00000034255010fd in RexxExpressionFunction::evaluate (this=0x7f2bf14e0900, context=0x7f2bf14c7f00, stack=0x7f2bf14c8048)
6 0x00000034255023d6 in RexxBinaryOperator::evaluate (this=0x7f2bf14e0950, context=0x7f2bf14c7f00, stack=0x7f2bf14c8048)
7 0x00000034255023c3 in RexxBinaryOperator::evaluate (this=0x7f2bf14e0990, context=0x7f2bf14e0220, stack=0x7f2bf14c7fd0)
8 0x00000034255023c3 in RexxBinaryOperator::evaluate (this=0x7f2bf14e09d0, context=0x7f2bf14e0220, stack=0x7f2bf14c7fd0)
9 0x00000034255023c3 in RexxBinaryOperator::evaluate (this=0x7f2bf14e0a10, context=0x7f2bf14e0220, stack=0x7f2bf14c7fd0)
10 0x000000342550515b in RexxInstructionCall::execute (this=0x7f2bf14e11f0, context=0x7f2bf14c7f00, stack=0x7f2bf14c8048)
11 0x00000034254d7fad in RexxActivation::run (this=0x7f2bf14c7f00, _receiver=<value optimized="" out="">, msgname=<value optimized="" out="">, _arglist=0x3424409410,
12 0x00000034254dcfac in RexxCode::call (this=<value optimized="" out="">, activity=0x7f2bf14ce9e0, routine=0x7f2bf14d1890, msgname=0x7f2bf27ff4a0, argPtr=0x7f2bf14d1780,
13 0x00000034254b6a22 in RoutineClass::runProgram (this=<value optimized="" out="">, activity=0x7f2bf14e0220, calltype=<value optimized="" out="">,
14 0x00000034254fa7ed in RexxStartDispatcher::run (this=0x7fff6e2c34c0) at interpreter/concurrency/RexxStartDispatcher.cpp:138
15 0x00000034254de474 in RexxNativeActivation::run (this=0x7f2bf14d14f0, dispatcher=...) at interpreter/execution/RexxNativeActivation.cpp:1532
16 0x00000034254f9bf8 in RexxActivity::run (this=0x7f2bf14ce9e0, target=...) at interpreter/concurrency/RexxActivity.cpp:2944
17 0x00000034254f4984 in ActivityDispatcher::invoke (this=0x7fff6e2c34c0, exits=<value optimized="" out="">, env=<value optimized="" out="">)
18 0x00000034254cbf9d in RexxStart (argcount=1, arglist=0x7fff6e2c35f0, programname=0x7fff6e2c66f1 "/home/john/execs/kld", instore=0x0, envname=0x400c84 "bash",
19 0x0000000000400b3e in main (argc=3, argv=<value optimized="" out="">) at utilities/rexx/platform/unix/rexx.cpp:169
Hi John,
Could you verify for me:
1.) The OS is Fedora Core 13 64 bit?
2.) Did you reinstall from a package downloaded from Source Forge? Which one?
There were a number of bug fixes in ooRexx 4.0.1. I don't see any down side in installing 4.0.1.
Yes, it is Fedora 13 64 bit AMD.
No I have not re-installed.
Hi John,
You need to re-install using one of the rpm packages that we built. One of the release packages we have on SourceForge.
1.) "I installed oorexx with yum." In the past these packages have not been built correctly.
2.) I know for a fact that you have to be careful when building on Linux, that it is very easy to end up with problems in either rexximage or rexxutil.
I think it's likely that the problem comes from the rpm package, not from ooRexx itself.
One of the nice things about a rpm package is it very quick and simple to reinstall. Please reinstall and then let me know if you still get crashes.
I'm setting the resolution to postponed. When you reinstall, if you still get crashes set the resolution back to none. If you don't get crashes, after a sufficient amount of time in your mind, then close the bug. Set Status to closed and resolution to invalid.
I'm going to close this bug because:
1.) We can only support packages built by the ooRexx team, we know that packages built by Linux distributors have had problems in the past.
2.) John hasn't provided any feed back about trying a package downloaded from SourceForge.
3.) It is way out of date.