Yup, using SIGHUP works. On 29 July 2014 13:14, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:> Could it be that I'm misunderstanding signal semantics, and SIGUSR1 is > not guaranteed to be delivered (to the same process!) before kill() > returns? Could you check if that's what happens by adding a sleep() > somewhere? > > On Tue, Jul 29, 2014 at 2:17 AM, Renato Golin <renato.golin at linaro.org> wrote: >> Hi Evgeniy, >> >> Yes, it is. The problem here is that the program doesn't fail on my >> box (release and debug builds), so I have no idea how to debug the >> problem. According to the test, it's ran as "not >> chained_origin_with_signals.cc.tmp", expecting it to fail. Also, the >> FileCheck expects to find warnings on the output, for which there is >> none >> >> Maybe I'm missing some CMake flag or library, and that's why the >> signal functionality is not working on my box? >> >> cheers, >> --renato >> >> On 25 July 2014 09:39, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: >>> Hi, >>> >>> is it still an issue? >>> Just by looking at the code, I don't see why it could fail. Do you >>> need any help debugging it? >>> >>> On Wed, Jul 23, 2014 at 1:15 AM, Renato Golin <renato.golin at linaro.org> wrote: >>>> I'm compiling compiler-rt via CMake+Ninja on x86_64+ArchLinux and one >>>> of the tests fails on ToT: >>>> >>>> MemorySanitizer :: chained_origin_with_signals.cc >>>> >>>> The text expects uninitialized warnings while the execution prints >>>> nothing, thus FileCheck fails. >>>> >>>> Anyone seeing this? >>>> >>>> cheers, >>>> --renato >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
You mean replacing SIGUSR1 with SIGHUP in the test case? Weird, I
don't see how they are different.
POSIX.1-2001 requires that if a process sends a signal to itself,
and the sending thread
does not have the signal blocked, and no other thread has it
unblocked or is waiting for it
in sigwait(3), at least one unblocked signal must be delivered
to the sending thread before
the kill() returns.
On Tue, Jul 29, 2014 at 5:51 PM, Renato Golin <renato.golin at linaro.org>
wrote:> Yup, using SIGHUP works.
>
> On 29 July 2014 13:14, Evgeniy Stepanov <eugeni.stepanov at
gmail.com> wrote:
>> Could it be that I'm misunderstanding signal semantics, and SIGUSR1
is
>> not guaranteed to be delivered (to the same process!) before kill()
>> returns? Could you check if that's what happens by adding a sleep()
>> somewhere?
>>
>> On Tue, Jul 29, 2014 at 2:17 AM, Renato Golin <renato.golin at
linaro.org> wrote:
>>> Hi Evgeniy,
>>>
>>> Yes, it is. The problem here is that the program doesn't fail
on my
>>> box (release and debug builds), so I have no idea how to debug the
>>> problem. According to the test, it's ran as "not
>>> chained_origin_with_signals.cc.tmp", expecting it to fail.
Also, the
>>> FileCheck expects to find warnings on the output, for which there
is
>>> none
>>>
>>> Maybe I'm missing some CMake flag or library, and that's
why the
>>> signal functionality is not working on my box?
>>>
>>> cheers,
>>> --renato
>>>
>>> On 25 July 2014 09:39, Evgeniy Stepanov <eugeni.stepanov at
gmail.com> wrote:
>>>> Hi,
>>>>
>>>> is it still an issue?
>>>> Just by looking at the code, I don't see why it could fail.
Do you
>>>> need any help debugging it?
>>>>
>>>> On Wed, Jul 23, 2014 at 1:15 AM, Renato Golin <renato.golin
at linaro.org> wrote:
>>>>> I'm compiling compiler-rt via CMake+Ninja on
x86_64+ArchLinux and one
>>>>> of the tests fails on ToT:
>>>>>
>>>>> MemorySanitizer :: chained_origin_with_signals.cc
>>>>>
>>>>> The text expects uninitialized warnings while the execution
prints
>>>>> nothing, thus FileCheck fails.
>>>>>
>>>>> Anyone seeing this?
>>>>>
>>>>> cheers,
>>>>> --renato
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 29 July 2014 15:02, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:> You mean replacing SIGUSR1 with SIGHUP in the test case? Weird, I > don't see how they are different.So, AFAIK, they should be identical. But I put some printfs and sleeps around and it wasn't a synchronization issue. My man page says that SIGUSR1 should terminate if there isn't a handler for it (different than SIGINFO), but the process didn't terminate neither ran the handlers, which is odd. SIGHUP didn't have that behaviour, and executed the handler. I'm not an expert in signals, so I can't comment on that part. But given that this test is not about signals, but about the uninitialized variable, I guess making it SIGHUP wouldn't hurt too much. :) cheers, --renato