This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] S/390: Fix makecontext with uc_link == NULL


On 07/16/2012 10:19 AM, Thomas Schwinge wrote:
> Hi!
> 
> On Thu, 12 Jul 2012 09:38:35 -0400, Carlos O'Donell <carlos_odonell@mentor.com> wrote:
>> On 7/12/2012 8:19 AM, Andreas Krebbel wrote:
>>>> Do we have a testcase that covers this failure?
>>>>
>>>> If we don't, could you try to work one up?
>>>
>>> stdlib/tst-makecontext already calls makecontext with uc_link == NULL
>>> but the function invoked in the context does explicitly call exit (0).
>>> Removing this enables the testcase to cover that problem as well.
> 
>>> 	* stdlib/tst-makecontext.c: Remove explicit exit call.
>>
>> Excellent. The testcase changes look good to me and match what
>> SuSv2 says about a returning from a context where uc_link is
>> zero e.g. "the thread will exit when this context returns."
>>
>> I'm happy with this, thanks for enhancing the testcase to cover
>> the failure scenario.
> 
> I already raised this topic in
> <http://news.gmane.org/find-root.php?message_id=%3C87lijq5h72.fsf@schwinge.name%3E>:
> 
> | [a bug is only seen] when returning from a context with Âuc_link ==
> | NULLÂ, which is not exercised in the testsuite.
> | 
> | I first though about simply removing the Âexit (0)Â from
> | stdlib/tst-makecontext.c:cf (which would then test exactly this case),
> | but apparently it is not specified which status value to use for exit in
> | this case -- libc.info: ÂIf `uc_link' was a null pointer the application
> | terminates in this case. -- so it is not trivial to test for.  (Maybe
> | worth specifying?  EXIT_SUCCESS (0)?)
Ok. Thanks for the pointer. I think everything other than 0 doesn't make much sense since
exiting that way is not caused by any kind of error.

I could check in the testcase change removing the exit and we could make the back-end
maintainers aware of the problem with their target. What do you think?

Bye,

-Andreas-

Bye,

-Andreas-


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]