C++ thread exceptions problem

[Denis Kukharev]

I have a problem when catching a plenty of exceptions simultaneously in different threads: the Load Average indicator exceeds 100.0 and the process seems to "hang up".
I managed to simulate this situation having created a test program with a number of threads about 200 each containing a FINITE loop with throwing and catching an exception. The exceptions don't leave thread function. The test starts to work and at some moment blocks. Under some other conditions the test may finish (when number of threads is lower or when intervals between throwing exceptions are bigger). It can pass even with the same conditions, so it's behavior is unpredictable.
I use boost::thread over libpthread and g++ 4.2.1 on 2-core amd64 with FreeBSD7.0. It's interesting that under Linux this test runs smoothly.

when the test application hangs, I kill it with -11 signal and that is what I see in gdb:
(gdb) where
#0 0x0000000801554 636 in __fixunssfti () from /lib/libgcc_s.so.1
]#1 0x00000008005c6 343 in dl_iterate_phdr () from /libexec/ld-elf.so.1
#2 0x0000000801554 bdf in _Unwind_Find_FD E () from /lib/libgcc_s.so.1
#3 0x0000000801551 525 in _Unwind_GetIPIn fo () from /lib/libgcc_s.so.1
#4 0x0000000801552 96e in _Unwind_RaiseEx ception () from /lib/libgcc_s.so.1
#5 0x00000008012a2 abd in __cxa_throw () from /usr/lib/libstdc++.so.6
.....

The same is in my real application when it hangs on exceptions.

[weaknessforcats]

Probably this is a deadlock where more then one thread is waiting on a resource owned by the other thread.

How are you handling locking where common resources are used?

[Denis Kukharev]

Probably this is a deadlock where more then one thread is waiting on a resource owned by the other thread.

How are you handling locking where common resources are used?

well, test code doesn't seem to utilize any shared resource. Here is test thread routine:

void ThreadProc()
{
        cerr << "I'm working!!!" << endl;

        srand(time(NULL));

        //Throw and catch 10 exceptions
        for (int i = 0;i < 10;i++)
        {
            unsigned int seedTmp;
            try
            {
                //random waiting between throws
                int rand = (int) (500000 * ( (double) rand_r (&seedTmp) / RAND_MAX));
                usleep(rand);

                //throw my exception
                throw ExceptionBase ("debug!");
            }
            catch (ExceptionBase &e)
            {
                cerr << "Exception "<<i<<" has been caught: " << e.Message() << endl;
            }
        }
}

[Denis Kukharev]

Hadn't nobody faced the problem? Hey, gurus, try this test case, it's not so hard to do! :) You can replace the ExceptionBase with std::exception, the result was similar for me. If there is a problem in libraries - it should be uncovered, or may be I do something incorrect? Please, help me, for the problem disturbs working of production system for the long period!

[JosAH]

Hadn't nobody faced the problem? Hey, gurus, try this test case, it's not so hard to do! :) You can replace the ExceptionBase with std::exception, the result was similar for me. If there is a problem in libraries - it should be uncovered, or may be I do something incorrect? Please, help me, for the problem disturbs working of production system for the long period!

This is just a guess; I don't have any (free)BSD installations here; btw, it ran fine
on my Linux box. My guess is that the stack unwinding goofs somewhere when
multiple threads are involved. Can you try to throw and catch a pointer to your
exception instead? (and delete the exception in your catch clause of course).

It would be a clumsy workaround but maintaining a single pointer from one stack
context is a bit easier than maintaining an entire local exception object.

As I wrote, this is just a guess ...

kind regards,

Jos

[Denis Kukharev]

This is just a guess; I don't have any (free)BSD installations here; btw, it ran fine
on my Linux box. My guess is that the stack unwinding goofs somewhere when
multiple threads are involved. Can you try to throw and catch a pointer to your
exception instead? (and delete the exception in your catch clause of course).

It would be a clumsy workaround but maintaining a single pointer from one stack
context is a bit easier than maintaining an entire local exception object.

As I wrote, this is just a guess ...

kind regards,

Jos

Thank You for urgent attention! I'll try Your suggestion.
PS (As I mentioned in the initial message, on my Linux it works fine too... and that's the miracle! :) )

[JosAH]

Thank You for urgent attention! I'll try Your suggestion.
PS (As I mentioned in the initial message, on my Linux it works fine too... and that's the miracle! :) )

Any (positive) results already?

kind regards,

Jos

[Denis Kukharev]

Any (positive) results already?

kind regards,

Jos

Unfortunately, no... The result is the same.

throw new std::exception();
...
catch (std::exception *e)
{
...
delete e;
}

[JosAH]

Does any of the versions work properly in one single thread? If so I guess your
standard libraries are a bit goofy. Any alternative versions available? Any known
bug-report on this particular issue?

kind regards,

Jos

[Denis Kukharev]

Does any of the versions work properly in one single thread? If so I guess your
standard libraries are a bit goofy. Any alternative versions available? Any known
bug-report on this particular issue?

kind regards,

Jos

Yeah, 1-thread version works fine. I'll try to use other libs, but I tried the test on a number of systems under FreeBSD.
As for known bug reports - I've failed to find any...

Well, waiting for another experiments with this issue!

[JosAH]

Yeah, 1-thread version works fine. I'll try to use other libs, but I tried the test on a number of systems under FreeBSD.
As for known bug reports - I've failed to find any...

Well, waiting for another experiments with this issue!

Sorry that I can't help you any further (I don't even run a BSD version here). Is
there a proprietary compiler flag or a special order of include files that need to
be obeyed? I remember from an old version of the pthread library that it had to
be the first one to be linked ... (if I remember well)

kind regards,

Jos

[Denis Kukharev]

Sorry that I can't help you any further (I don't even run a BSD version here). Is
there a proprietary compiler flag or a special order of include files that need to
be obeyed? I remember from an old version of the pthread library that it had to
be the first one to be linked ... (if I remember well)

kind regards,

Jos

OK, I'll seek in that directions...
Thanx!

[JosAH]

OK, I'll seek in that directions...
Thanx!

Best of luck; there's one more thing I'd like to mention: on my Linux box the
stack levels just before the throw and in the catch block are equal as they
should be. I wonder if that is true in your BSD installation ...

kind regards,

Jos

[Denis Kukharev]

Best of luck; there's one more thing I'd like to mention: on my Linux box the
stack levels just before the throw and in the catch block are equal as they
should be. I wonder if that is true in your BSD installation ...

kind regards,

Jos

Kindly explain me how to display the stack levels?

[JosAH]

Kindly explain me how to display the stack levels?

Type 'where' without the quotes and pay special attention to the first column.

kind regards,

Jos