1. exu problem
--
Has anyone written a program in Eu for Linux had this problem.
I start running a program from a terminal emulation window.
The program runs with no errors.
After it exits the interpeter LInux displays the message :
Segmentation fault (core dumped)
( Where it dumped it, I have no idea )
I know that this means that something is trying to violate another
objects protected segment.
I wonder if the garbage collector is trying to use bad memory pointers
when the interpter is shuting down.
I can't think of anyway to trace this kind of problem.
Bernie
2. Re: exu problem
- Posted by Robert Craig <rds at ATTCANADA.NET>
Sep 24, 2000
-
Last edited Sep 25, 2000
Bernie Ryan writes:
> After it exits the interpeter LInux
> displays the message :
> Segmentation fault (core dumped)
If you send me the program, I'll see if it
does the same thing on my machine.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: exu problem
Bernie Ryan writes:
> After it exits the interpeter LInux displays
> the message : Segmentation fault (core dumped)
I ran your program on my Red Hat 5.2 installation.
It gave me the same error that you saw.
Your program contains a list of 500 .so files with
full path. When I run it, 71 of those files actually exist
on my machine and can be opened as shared libraries.
Through "binary search", I managed to isolate
"/usr/lib/libpthread.so". A segmentation violation
does not occur as long as this library
is commented out. If this library is included, a segmentation
fault occurs sometime *after* the Euphoria interpreter
does its final exit().
I don't think there is a bug in the interpreter.
Probably it's some strange Linux bug.
It could also be a bug in your code.
Your code looks ok, but I didn't check it thoroughly.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: exu problem
On Mon, 25 Sep 2000 15:45:56 -0400, Robert Craig <rds at ATTCANADA.NET> wrote:
>Through "binary search", I managed to isolate
>"/usr/lib/libpthread.so". A segmentation violation
>does not occur as long as this library
>is commented out. If this library is included, a segmentation
That doesn't help on my system, commenting it out I get the same
error.
If you comment out the if statement that uses the dlsym() then
the program is only opening and closing a shared library.
Doing this I still get the error.
The interpeter should not have this error when exiting after opening
and closing ANY shared library. That would mean the user could only use
certain selected libraries.
If a library can't be opened or closed it will return an error
but not cause an error on exit.
Thats why I think it is a problem with interpeter that only occurs
under certain conditions.
Thanks
Bernie
5. Re: exu problem
- Posted by Robert Craig <rds at ATTCANADA.NET>
Sep 25, 2000
-
Last edited Sep 26, 2000
Bernie Ryan writes:
> If I run the program and comment out the dlclose the error does
> not occur when the program exits.
When you open a .dll (or .so) on Linux the _init()
entry point is called. When you close a .so the _fini()
routine is called, if it's defined. Almost all of the .so's
on your list export _init() and _fini() symbols.
> The interpeter should not have this error when exiting
> after opening and closing ANY shared library.
Your program goes blindly through a list of 500 shared libraries,
opening and closing them, causing _init() and _fini()
routines to be invoked. You don't know what all those libraries
do, or how they are supposed to be used. It doesn't
surprise me that in one or two cases some instability might occur,
just by opening and closing, leading to an eventual
segmentation violation.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
6. Re: exu problem
--
I have more information about the problem.
If I run the program and comment out the dlclose the error does
not occur when the program exits.
I see disk activity after the program exit maybe thats the interpter
closing the shared libraries.
When the user uses open_dll() what mode are you using ?
The shared libraries can be opened in different modes maybe
when the user closes the shared library, a file pointer maybe
invalid when the program exits. The shared libraries have modes
that allow them to be moved in memory and that could invalidate
a pointer. Also when a shared library is closed it really doesn't
close unless no other process is using it.
Uncomment that file and try using the program without the dlclose
and see if the errror goes away.
Thanks
Bernie
