On Thu, 2007-05-10 at 11:33 +0200, Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > On Thu, 2007-05-10 at 10:34 +0200, Gilles Chanteperdrix wrote: > > > >>>> > > >>>> > Ok, I could reproduce the problem. The issue is most likely an access > >>>> > to > >>>> > the thread memory after it has been freed which breaks the allocator > >>>> > linked list of free pages by replacing a link to a next free page by a > >>>> > NULL pointer. xnheap_alloc interprets this NULL pointer as the end of > >>>> > the > >>>> > linked list and hence considers that it is out of memory. > >>>> > >>>>And the winner is... RPI! The offset of the thread structure member that > >>>>is set to NULL is the one of the rpi pointer. Disabling RPI makes the > >>>>problem vanish. > >>>> > >>>>Philippe, when is this pointer set to NULL ? > >>>> > >>> > >>>When the thread leaves secondary mode or exits, which in turn removes it > >>>from the queue the nucleus considers for priority boosting the root > >>>thread. Check rpi_none(). > >> > >>Conclusion: the problem is the one Andrew spotted, there are two > >>hooks and the shadow hook (which calls xnshadow_unmap, which in turn > >>calls rpi_pop, which sets the rpi pointer to null) gets called after the > >>other thread deletion hook which initially called xnfree, and now calls > >>xnfreesafe. > >> > >>But it seems that even xnfreesafe is not safe enough, and it frees the > >>thread pointer immediately whereas we would like the operation to be > >>deferred. > >> > > > > > > xnfreesafe was meant to prevent the caller from releasing some memory it > > could still rely on, e.g. stack space, by postponing the actual release > > until the idle thread is resumed. In your case, the problem is that it > > does not account for the primary/secondary mode of a shadow thread. > > I am not so sure. I mean, even if the thread was deleted from the > context of another thread, the two hooks would be invoked and we would > need the free operation to be deferred until after the execution of the > second hook. >
The point is that deletion hooks are always called on behalf of the exiting thread in secondary mode, so if xnfreesafe properly identifies the caller as the current thread - regardless of its exec mode - then the deferral should always take place. But I agree on the fact that we should always end up running the deferred call in this context anyway, so we would be better off calling xnheap_schedule_free() directly. -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
