[kde-freebsd] [CODE] Multithreaded SIGSEGV signal handling, please examine

[David Naylor]

Hi Michael,

I'm not sure if you have received results for FreeBSD but on my system I get:

# uname -a
FreeBSD dragon.dg 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Wed Sep 21 06:45:41 SAST 
2011     root@:/usr/obj/home/freebsd9/src/sys/MODULAR  amd64

# g++ -pthread -o sigcatcher sigcatcher.cpp
# ./sigcatcher 
Hello, World!
Got a result of 1
Exited thread

# clang++ -pthread -o sigcatcher sigcatcher.cpp
# ./sigcatcher
Hello, World!
Got a result of 1
Exited thread

Of note: library `rt' does exist on FreeBSD but does not change the results 
above, nor does using optimisations of 2 or 3.  

Thank you for your work.

David

On Sunday, 25 September 2011 01:37:12 Michael Pyne wrote:
> Hi,
> 
> I writing with a kind of sneak preview of a change I would like to make to
> KSharedDataCache (kdelibs/kdecore/util) in KDE 5.
> 
> The idea is to use a separate thread to perform the operations that
> actually access shared memory, since a good majority of KSharedDataCache
> bugs are reported as resolved by the user when they remove the cache file
> and allow it to be regenerated.
> 
> While it is best to ensure there's absolutely no logic errors in the cache,
> that's not the only source of cache corruption (BleachBit being run in a
> naïve mode of operation being the other popular source). With this change
> KSharedDataCache will be able to unlink the corrupted cache *and* prevent
> application crashes.
> 
> It utilizes several nuances of what I believe to be fully POSIX/SUSv3-
> compliant code:
> 
> * The idea that SIG{SEGV,FPE,ILL,BUS} signals are directed to a specific
> thread (i.e. the thread that was running the code that invoked those
> signals).
> 
> * The idea that signal masks are per-thread (so that only the signals
> listed above would be delivered to the canary thread).
> 
> * Oh, and that sigsetjmp/siglongjmp actually work correctly. ;)
> 
> With that said I don't think the code uses as many POSIX options as the
> rest of KSharedDataCache (e.g. process-shared mutexes as unimplemented on
> Mac OS X) but I wanted to give a chance for you guys to test the prototype
> code beforehand and let me know if there's problems.
> 
> You'll want to compile with something like this:
> $CXX -O2 -o sigcatcher -lrt -pthread sigcatcher.cpp
> 
> Make sure optimization is enabled to ensure volatile is used where it's
> needed. Assuming everything works right you should get output like:
> 
> $ ./sigcatcher
> Hello, World!
> Got a result of 1
> Exited thread
> $
> 
> If you want to see the signal handler in action there's a couple of lines
> you can uncomment (just grep for uncomment to find where).
> 
> Obviously any other feedback on possible issues is appreciated as well, but
> basically I'd like to catch any portability issues early this time instead
> of after-the-fact.
> 
> Please CC me on any replies as I'm not subscribed.
> 
> Regards,
>  - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-freebsd/attachments/20111009/04a9505d/attachment.sig>