#2282 SIGSEGV in tool_mm_flush()

[Klaus Kämpf]

If a provider crashes early (i.e. during init) and sfcb is stopped, internal providers might SIGSEGV in tool_mm_flush().

Analyzing the resulting core (see tracker id 3416054) shows that __mm_key is not initialized (== 0) but CMPI_BrokerExt_Ftab->getThreadSpecific() returns a pointer to uninitialized memory.

[Klaus Kämpf]

Hmm, looks like the patch is not sufficient. I still get segfaults in tool_mm_flush() and __mm_key_valid is 1

[Klaus Kämpf]

The patch was bogus. Its a race issue. Adding i.e. a printf statement to __init_mt() prevents the segfault

[Klaus Kämpf]

Btw, its perfectly reproducable for me with sfcb 1.3.13 when starting and immediately stopping sfcbd. Then InteropProvider and ProfileProvider both crash.

[Klaus Kämpf]

In support.c, tool_mm_flush() calls __flush_mt() with a value which was never created by __init_mt() - memory corruption ?!

[Klaus Kämpf]

Reading from "man pthread_getspecific"

The effect of calling pthread_getspecific() or pthread_setspecific() with a key value not obtained from pthread_key_create() or after key has been deleted with pthread_key_delete() is undefined.

[Klaus Kämpf]

The crashing providers have identical values of pthread_self() !

[Klaus Kämpf]

Better fix: don't call tool_mm_flush during OPS_LoadProvider

[Klaus Kämpf]

Not calling tool_mm_flush() seems to be a better option.

[Narasimha Sharoff]

If an interrupt occurs at startup, depending on the state of processes, segfault can occur. The patch masks sigint when processes are starting up and enables it back again after that.

[Narasimha Sharoff]

[Narasimha Sharoff]

this fix applies for cvs head

[Michael Chase-Salerno]

This is LTC#75891

[Narasimha Sharoff]

updated the fix to apply for the latest CVS head

[Narasimha Sharoff]

patch applied to cvs head

[Chris Buccella]

committed to git Apr 4