I can. I've removed every other compilation flags from clang and even used GCC, with the exact same behaviour. cheers, --renato On 29 July 2014 15:15, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:> OK, we can switch to SIGHUP. Could you please verify that this SIGUSR1 > behavior is not caused by MSan? > > On Tue, Jul 29, 2014 at 6:09 PM, Renato Golin <renato.golin at linaro.org> wrote: >> 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
r214289. On Tue, Jul 29, 2014 at 6:25 PM, Renato Golin <renato.golin at linaro.org> wrote:> I can. I've removed every other compilation flags from clang and even > used GCC, with the exact same behaviour. > > cheers, > --renato > > On 29 July 2014 15:15, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: >> OK, we can switch to SIGHUP. Could you please verify that this SIGUSR1 >> behavior is not caused by MSan? >> >> On Tue, Jul 29, 2014 at 6:09 PM, Renato Golin <renato.golin at linaro.org> wrote: >>> 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
Worked, thanks! On 30 July 2014 09:37, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:> r214289. > > On Tue, Jul 29, 2014 at 6:25 PM, Renato Golin <renato.golin at linaro.org> wrote: >> I can. I've removed every other compilation flags from clang and even >> used GCC, with the exact same behaviour. >> >> cheers, >> --renato >> >> On 29 July 2014 15:15, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: >>> OK, we can switch to SIGHUP. Could you please verify that this SIGUSR1 >>> behavior is not caused by MSan? >>> >>> On Tue, Jul 29, 2014 at 6:09 PM, Renato Golin <renato.golin at linaro.org> wrote: >>>> 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