Status: New
Owner: ----
Labels: Version Type-Bug Priority-Medium OpSys-Any Dist-Any Arch-Any  
Desktop-Any GUI-Any

New issue 226 by x1f3o3...@gmail.com: SIGSEGV handler overwritten (for too  
long)
http://code.google.com/p/gambas/issues/detail?id=226

1) Describe the problem.

"main/gbx/gbx_stream_memory.c"

In "static int stream_read(STREAM *stream, char *buffer, int len)" the  
current SIGSEGV signal handler is replaced by CHECK_enter(). This is  
probably done to catch errors during memory access.
However, a problem arises when using a library which also uses a SIGSEGV  
handler, and at the same time uses a background thread which depends on  
that particular handler.

I was not yet able to test this further, but when the background thread  
crashes the gambas signal handler seems to receive the error, it will  
therefore crash. You get a signal #11 error from gambas.

The same problem also applies to the "type@()" functions.

2) GIVE THE FOLLOWING INFORMATIONS (if they are appropriate):

Version: TRUNK
Revision: All, at the time of writing r4384
Operating system: All, tested on Linux
Distribution: All, tested on ArchLinux
Architecture: All, tested on x86_64
GUI component: All
Desktop used: All

3) Provide a little project that reproduces the bug or the crash.
4) If your project needs a database, try to provide it, or part of it.

Not necessary yet

5) Explain clearly how to reproduce the bug or the crash.

1. Create a thread in an "extern" function and set up a SIGSEGV handler
a2. In the thread, do something to trigger the SIGSEGV handler
a3. In the SIGSEGV handler handle the error and continue execution
b2. Try to access memory using a pointer from your gambas application
4. *Crash*

A possible solution would be to add an "unsafe" mode which would disable  
the CHECK_* signal handlers. An alternative would be to warn the user if an  
error handler was already installed before, then continue without error  
handling.

As a temporary solution I wrote my own set of memory access functions in  
another library which simply work like the "type@" functions. However, this  
requires unnecessary support code. It also means that you have to carry a  
module or classname around.

However, this probably affects other functions using the CHECK_*()  
functions too.


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user

Reply via email to