1. eu 3.1.1 problem
- Posted by kinz_linux May 04, 2009
- 857 views
Dear Devs,
There seems to be a problem with source code of eu 3.1.1 interpreter for Linux.
I've tried to compile it on my Mandriva 2008.0 with gcc 4.2.2. This compiled interpreter works
with ascii.ex, sanity.ex (100% pass) etc, but crashes on all demos from euphoria\demo\linux
directory with message about machine exception or bad segmentation.
But the Official interpreter works OK.
What to do?
Thanks!
Regards,
kinz
2. Re: eu 3.1.1 problem
- Posted by ChrisB (moderator) May 04, 2009
- 834 views
Hi
Thats not enough info. How did you compile the program, what Linux are you using (I find trying to compile with 64 bit Linux and GCC a headache when you have a lot of 32 bit and 64 bit libraries intertwined), more detail about the crash messages, and what other tests have you done, and can you create a small program that highlights the crash.
Don't mean to be vague or evasive, but interpretation of bug reports is often an art form in itself.
Chris
3. Re: eu 3.1.1 problem
- Posted by kinz May 04, 2009
- 813 views
Hi
Thats not enough info. How did you compile the program,
My gcc package version is 4.2.2-3.1mdv2008.0.
I used the official standard command imakeu in the /root/euphoria/source/
directory. Translation and compilation was without any errors, the resulting
new interpreter, exu, is 343961 bytes. But the official interpreter is 338084 bytes.
Both interpreters tested on the ascii.ex and sanity.ex standard programs, worked
Ok. Then they tested on standard demos in euphoria/demo/linux/ directory.
Official one worked OK on all programs. But new one crashed on all programs.
what Linux are you using (I find trying to compile with 64 bit Linux and GCC a headache when you have a lot of 32 bit and 64 bit libraries intertwined),
My Linux is Mandriva 2008.0, free, 3CD, Russian, 32 bit, updated on all available
now packages. My machine is P4, 1.8GHz, 256Mb, IBM Netvista, dual boot, Windows XP SP3 Home and that Linux. On XP with OW1.8, EU 3.1.1 official source works without any problem, plus bilingual 3.1.1 source for DOS32 and WIN32 works OK.
more detail about the crash messages, and what other tests have you done, and can you create a small program that highlights the crash.
I've tested all standard demo programs in the euphoria/demo/linux/ directory. They are callc.exu, mylib.exu and qsort.exu. callc.exu and qsort.exu crash on a machine-level exception. The ex.err files see please below.
callc.exu:30 A machine-level exception occurred during execution of this statement Global & Local Variables /root/euphoria/include/machine.e: mem = 135057744 check_calls = 1 callc.exu: libc = 135086760 libm = 135097232 p = 135119200 q = 135097176 format = <no value> text = <no value> s = 0 a = 10 ----------------------------- qsort.exu:41 A machine-level exception occurred during execution of this statement Global & Local Variables /root/euphoria/include/machine.e: mem = 135072656 check_calls = 1 qsort.exu: libc = 135110808 qid = 0 nitems = 50'2' item_size = 1 qsort = 0 ncalls = 0 qaddr = 135072696 array = 135113576
The mylib.exu crashes on segmentation error, without ex.err file, output:
#exu mylib.exu 99 Segmentation error -- or something similar, Mandriva speaks Russian here.
Don't mean to be vague or evasive, but interpretation of bug reports is often an art form in itself.
Yes, you are right, the bug-report must be clear. As you can see all crashes are around calls of C-functions from .so libs.
Regards,
kinz
4. Re: eu 3.1.1 problem
- Posted by jimcbrown (admin) May 04, 2009
- 807 views
This is a known issue with 3.1.1 source.
The problem is due to call c offsets. So 3.1.1 is set up to only work with a specific linux distro and a specific gcc compiler version because these values are hardcoded.
This was not fixed until eu 4.0 (pre-alpha, specifically svn rev 498 for gcc and svn rev 502 for watcom wcc386). So to make this work you'll either need to use a support distro and gcc version (I don't remember offhand what was supported, maybe Jeremy can chip in here) or manually calculate and update the offset values yourself. Note, if you choose the later tasks will still be broken: those were not fixed until svn rev 1028.
5. Re: eu 3.1.1 problem
- Posted by jeremy (admin) May 04, 2009
- 794 views
I do not remember. I do know that switching even between a minor version of Ubuntu was giving some problems. I sure am glad we got that all sorted out in 4.0. (Jim did that, BTW...).
As for calculating the offsets, I wonder if he could pull some of the code from the 4.0 be_callc.c file Jim?
Jeremy
6. Re: eu 3.1.1 problem
- Posted by jimcbrown (admin) May 04, 2009
- 823 views
As for calculating the offsets, I wonder if he could pull some of the code from the 4.0 be_callc.c file Jim?
Should be fairly simple. The be_callc.c that the patches were applied to was unchanged from 3.1.1, so one can just use an svn diff to create the patches and then apply them directly to 3.1.1's be_callc.c
Maybe it'd make sense to release a 3.1.1.1 (or 3.1.2) that fixes stuff like this but doesn't have any of the feature or functionality changes.
7. Re: eu 3.1.1 problem
- Posted by bernie May 04, 2009
- 816 views
This is a known issue with 3.1.1 source.
The problem is due to call c offsets. So 3.1.1 is set up to only work with a specific linux distro and a specific gcc compiler version because these values are hardcoded.
This was not fixed until eu 4.0 (pre-alpha, specifically svn rev 498 for gcc and svn rev 502 for watcom wcc386). So to make this work you'll either need to use a support distro and gcc version (I don't remember offhand what was supported, maybe Jeremy can chip in here) or manually calculate and update the offset values yourself. Note, if you choose the later tasks will still be broken: those were not fixed until svn rev 1028.
I think redhat 7 was what Rob was using.
8. Re: eu 3.1.1 problem
- Posted by jimcbrown (admin) May 04, 2009
- 813 views
I think redhat 7 was what Rob was using.
That's disturbing...
9. Re: eu 3.1.1 problem
- Posted by kinz_linux May 05, 2009
- 855 views
As for calculating the offsets, I wonder if he could pull some of the code from the 4.0 be_callc.c file Jim?
Should be fairly simple. The be_callc.c that the patches were applied to was unchanged from 3.1.1, so one can just use an svn diff to create the patches and then apply them directly to 3.1.1's be_callc.c
I've used be_callc.c of 4.0a3 in 3.1.1 source just now. It seems to work OK with Win32 and Dos32, but, sorry, on Linux, gives me the message:
[root@localhost source]# gcc be_callc.c be_callc.c: In function ‘call_c’ be_callc.c:447: error: expected ‘)’ before ‘__stdcall’ be_callc.c:447: eroor: expected ‘)’ before ‘(’ token be_callc.c:447: error: expected ‘)’ before ‘int_proc_address’ be_callc.c:464: eroor: expected ‘)’ before ‘__stdcall’ be_callc.c:464: eroor: expected ‘)’ before ‘(’ token be_callc.c:464: error: expected ‘)’ before ‘int_proc_address’ be_callc.c:481: error: expected ‘)’ before ‘__stdcall’ be_callc.c:481: error: expected ‘)’ before ‘(’ token be_callc.c:481: error: expected ‘)’ before ‘int_proc_address’ [root@localhost source]#
Maybe it'd make sense to release a 3.1.1.1 (or 3.1.2) that fixes stuff like this but doesn't have any of the feature or functionality changes.
Yes, it will be very good solution. 3.x is a traditional package, compatible with the Archive.
Regards
kinz
10. Re: eu 3.1.1 problem
- Posted by jimcbrown (admin) May 05, 2009
- 822 views
I've used be_callc.c of 4.0a3 in 3.1.1 source just now. It seems to work OK with Win32 and Dos32, but, sorry, on Linux, gives me the message:
[root@localhost source]# gcc be_callc.c be_callc.c: In function ‘call_c’ be_callc.c:447: error: expected ‘)’ before ‘__stdcall’ be_callc.c:447: eroor: expected ‘)’ before ‘(’ token be_callc.c:447: error: expected ‘)’ before ‘int_proc_address’ be_callc.c:464: eroor: expected ‘)’ before ‘__stdcall’ be_callc.c:464: eroor: expected ‘)’ before ‘(’ token be_callc.c:464: error: expected ‘)’ before ‘int_proc_address’ be_callc.c:481: error: expected ‘)’ before ‘__stdcall’ be_callc.c:481: error: expected ‘)’ before ‘(’ token be_callc.c:481: error: expected ‘)’ before ‘int_proc_address’ [root@localhost source]#
You are doing it the wrong way. You need to use imakeu to build on Linux, runningcc directly is possible but it requires you to know exactly which defines and options to pass. (You could figure this out by reading imakeu, though.) In short, you haven't passed -DELINUX so be_callc.c assumed you were using Watcom on Windows, and then gcc balks at stdcall (which is only valid on Windows).
11. Re: eu 3.1.1 problem
- Posted by kinz_linux May 05, 2009
- 822 views
You are doing it the wrong way. You need to use imakeu to build on Linux, runningcc directly is possible but it requires you to know exactly which defines and options to pass. (You could figure this out by reading imakeu, though.) In short, you haven't passed -DELINUX so be_callc.c assumed you were using Watcom on Windows, and then gcc balks at stdcall (which is only valid on Windows).
Ok, it seems to work now for me on Linux, in bilingual mode too. But it needs -DELINUX -DEUNIX in imakeu just for itself. It doesn't work with separate -DELINUX, it doesn't work with separate -DEUNIX, but it works with -DELINUX -DEUNIX. Strange.
Thanks.
Regards,
kinz
