|
From: <sv...@va...> - 2005-11-13 11:52:43
|
Author: tom
Date: 2005-11-13 11:52:39 +0000 (Sun, 13 Nov 2005)
New Revision: 5114
Log:
Preserve the sign of the bottom 16 bits of si_code when discarding
the top 16 bits - the pthread library uses negative code values in
the signals it sends between threads.
Modified:
trunk/coregrind/m_signals.c
Modified: trunk/coregrind/m_signals.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_signals.c 2005-11-13 02:42:23 UTC (rev 5113)
+++ trunk/coregrind/m_signals.c 2005-11-13 11:52:39 UTC (rev 5114)
@@ -1359,7 +1359,7 @@
use and only exports the bottom 16 bits to user space - at least
that is the theory, but it turns out that there are some kernels
around that forget to mask out the top 16 bits so we do it here. *=
/
- info->si_code &=3D 0xffff;
+ info->si_code =3D (Short)info->si_code;
#endif
=20
/* The thread isn't currently running, make it so before going on */
@@ -1476,7 +1476,7 @@
use and only exports the bottom 16 bits to user space - at least
that is the theory, but it turns out that there are some kernels
around that forget to mask out the top 16 bits so we do it here. *=
/
- info->si_code &=3D 0xffff;
+ info->si_code =3D (Short)info->si_code;
#endif
=20
if (info->si_code <=3D VKI_SI_USER) {
|
|
From: Julian S. <js...@ac...> - 2005-11-13 14:26:46
|
> Preserve the sign of the bottom 16 bits of si_code when discarding
> the top 16 bits - the pthread library uses negative code values in
> the signals it sends between threads.
This was presumably the cause of the pth_cancel{1,2} failures?
Would it be safer not to modify the top 16 bits at all, but rather
to mask them just at the relevant use points?
J
|
|
From: Tom H. <to...@co...> - 2005-11-13 15:01:35
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> > Preserve the sign of the bottom 16 bits of si_code when discarding
> > the top 16 bits - the pthread library uses negative code values in
> > the signals it sends between threads.
>
> This was presumably the cause of the pth_cancel{1,2} failures?
Certainly pth_cancel2 yes.
> Would it be safer not to modify the top 16 bits at all, but rather
> to mask them just at the relevant use points?
In some way, yes. The advantage of current solution is that it
carries on working in a years time when somebody adds a new bit of
code that looks at si_code and forgets to mask it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-13 17:21:28
|
So in fact .. I'm a bit unclear about this. On the one hand it
seems, buggy kernels pass nonzero values in the upper 16 bits
of this when it should be zero. But on the other hand, the
implication of your commit is that libpthread relies on seeing
the sign of the whole 32 bit value. Can you clarify?
J
On Sunday 13 November 2005 14:27, Julian Seward wrote:
> > Preserve the sign of the bottom 16 bits of si_code when discarding
> > the top 16 bits - the pthread library uses negative code values in
> > the signals it sends between threads.
>
> This was presumably the cause of the pth_cancel{1,2} failures?
>
> Would it be safer not to modify the top 16 bits at all, but rather
> to mask them just at the relevant use points?
>
> J
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Tom H. <to...@co...> - 2005-11-13 17:27:06
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> So in fact .. I'm a bit unclear about this. On the one hand it
> seems, buggy kernels pass nonzero values in the upper 16 bits
> of this when it should be zero. But on the other hand, the
> implication of your commit is that libpthread relies on seeing
> the sign of the whole 32 bit value. Can you clarify?
The problem is that pthread_cancel uses the tgkill system call
to signal the other thread. Now sys_tgkill in the kernel sets
si_code to SI_TKILL which is -6 and normally when that siginfo
is later copied out to the signal handler the kernel masks off
the top 16 bits and then sign extends the bottom 16 so the result
in user space is still a negative value.
The kernel actually casts si_code to short as it copies it out, just
as my patch now does.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-11-13 17:42:37
|
On Sun, 13 Nov 2005, Tom Hughes wrote: > The problem is that pthread_cancel uses the tgkill system call > to signal the other thread. Now sys_tgkill in the kernel sets > si_code to SI_TKILL which is -6 and normally when that siginfo > is later copied out to the signal handler the kernel masks off > the top 16 bits and then sign extends the bottom 16 so the result > in user space is still a negative value. > > The kernel actually casts si_code to short as it copies it out, just > as my patch now does. I saw you wrote a comment about this in the code... did it include the above info? Nick |