Re: mudflap assert

[Eyal Lebedinsky <eyal at eyal dot emu dot id dot au>]

Frank Ch. Eigler wrote:
> Eyal Lebedinsky <eyal@eyal.emu.id.au> writes:
>
>
> > mf(3040975792): assertion failure: `pi->state == reentrant' in __mf_pthread_spawner at ../../../gcc/libmudflap/mf-hooks3.c:301
> > [...]
>
>
> This error suggests that something was corrupted with respect to
> libmudflap's tracking of threads.  Conceivably, it could relate to the
> prior dozen memory errors.  Does your program create a huge number of
> threads?

Not 'huge' but a few. This failing server will have 6-10 threads active
at a time. The assert shows up during the server shutdown time, when
only four thread are active.

My own internal tracing says that
1	a dummy thread on a join for [4]
2,3	housekeeping threads that are sleeping
4	the real server just accepted a client and is in pthread_create

I will accept the possibility that my own code is the source of
trouble, however I am looking for a way to verify this.

The violations in the log start with a 'malloc' violation - how
can I cause this?

[later]
Running with -crumple-zone=16 (was =0 before) I see this in the log:

free(): invalid pointer 0x8212f48!
free(): invalid pointer 0x8307860!
free(): invalid pointer 0x822c4d8!
free(): invalid pointer 0x822dac8!
free(): invalid pointer 0x815b3c8!
[the program aborted here]

This is the full log, no other violations are listed.

Watching this run I can say that the errors were reported while
the server was active, not during the shutdown. Also, all of my
programs report at least one free() error, none aborting.

In the past I avoided setting a positive -crumple-zone because
it has problems. I wonder if it is reliable now.

Running with -crumple-zone=4 I only get

free(): invalid pointer 0x815beb4!

and based on my internall tracing I see that the free() error
comes as I call
	pthread_join
before it returns, or after a thread calls
	pthread_exit
before another (the parent) returning from
	pthread_create

HTH

[another matter]

I have a patch (not installed) that adds wrappers for
	pthread_key_create
	pthread_key_delete
	pthread_setspecific
	pthread_getspecific
and I wonder if it is still needed or does libmudflap now
handles it in another way.

All these did was something like this
	__mf_state = reentrant;
	result = CALL_REAL (pthread_key_create, key, destructor);
	__mf_state = active;
but these now do not really work.

A wrapper for fork() that was working a few months ago started
causing failures after the library rewrite - does mf need one?

--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>
	attach .zip as .dat