Mailinglist Archive: opensuse-programming (16 mails)

[Jerry Feldman <gaf@xxxxxxx>]

On 05/31/2012 02:50 AM, Roger Oberholtzer wrote:
> On Wed, 2012-05-30 at 11:55 -0400, Jerry Feldman wrote:
> > On 05/30/2012 10:46 AM, Roger Oberholtzer wrote:
> > > On Wed, 2012-05-30 at 09:43 -0400, Jerry Feldman wrote:
> > > > On 05/30/2012 03:39 AM, Roger Oberholtzer wrote:
> > > > " If a process starts a thread, and that thread exits, the process does
> > > > not know about this until it tries to join the thread, right?"
> > > >
> > > > Not entirely true. There are a number of ways to allow a thread to exit 
> > > > avoiding the need to join. It has been a few years since I was working 
> > > > with pthreads, but you can set up a thread as detached. 
> > > > The main issue you need to understand is that unlike processes, threads 
> > > > run in the context of the thread creator. So, a segv in a thread will 
> > > > cause the entire process to fail. One of the things that really helps in 
> > > > thread programming is exception processing and try blocks. By wrapping 
> > > > sections of your code in try blocks you can avoid this nastiness. 
> > > > Additionally, if you have multiple child threads. Additionally I always 
> > > > recommend my former coworker, Dave Butenhof's books. 
> > > The 'fun' I am having is that in the past few months, three equipment
> > > suppliers have provided a Linux interface to their hardware. Generally
> > > this should be considered a good thing. All are implemented by starting
> > > threads. For two of the suppliers (GigE Vision cameras) I do not have
> > > the source and so cannot determine if they are doing things in the
> > > safest fashion. I really like threads and see that our application
> > > benefits from them greatly. We have used them for a couple years, But
> > > when something goes wrong. and especially if it is in a black box bit of
> > > code, life gets tedious. 
> > "life gets tedious"
> > Naw, fun :-)
> >
> > Thread debugging can be challenging. You can use some tools, like gdb.
> > I'm not sure, but IBM Rational's Purify was able to debug threads on
> > some platforms. I've never used Purify on Linux, only on Digital/Compaq
> > Tru64 Unix. However, you can still add try blocks to their code to help
> > a bit. Thread debugging. though, can provide a lot of challenges. The
> > first thing you need to know is if their code is thread-safe.
> One would imagine threaded code to be thread-safe. At least in
> intention, it not in reality. For the suspect libraries, I do not have
> the source.
>
> The symptom I see is that when I use one of these libraries, I then get
> a segmentation violation in libz. And I cannot see any problem with my
> call to gzwrite(). I am guessing that some part of the zlib data
> structure for the specific file has been corrupted by someone. The
> failure is always at the same point: a SIGPOLL signal results in a
> signal handler reading from a GPS, and the read data is sent to
> gzwrite(). The reads/writes are properly serialized. The signals do not
> interrupt themselves. When I add the thread library to the application
> so that there are threads reading from GigE Vision cameras, this problem
> can occur.
>
> If I don't enable the GPS reader, I do not get a failure. I suspect a
> memory corruption still occurs, but at some place that is 'innocent'.

Basically, signal handlers are not threadsafe. I would probably guess
that libz itself is not threadsafe. Additionally most of libc++ is also
not threadsafe. Lots of discussions online about this. You just need to
remember that threads run in the context of the user, and signal
handlers run in the context of root. If you are sharing memory with
memory used by the signal handler you are in very dangerous territory.

-- 
Jerry Feldman <gaf@xxxxxxx>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90