[Boost-users] [Test] valgrind complains about uninitialised data

35 views
Skip to first unread message

Jarl Friis

unread,
Jun 17, 2008, 8:36:59 AM6/17/08
to boost...@lists.boost.org
Hi.

I use valgrind 3.2.3.

When I run it on even simple Boost.Test unit tests, it complains about
use of uninitialised data, the report looks like this:
==11809== Memcheck, a memory error detector.
==11809== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==11809== Using LibVEX rev 1732, a library for dynamic binary translation.
==11809== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==11809== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==11809== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==11809== For more details, rerun with: -v
==11809==
==11809== Syscall param sigaltstack(ss) points to uninitialised byte(s)
==11809== at 0x8B1D3E7: sigaltstack (in /lib64/libc-2.6.1.so)
==11809== by 0x430CEA: boost::detail::signal_handler::~signal_handler() (execution_monitor.ipp:667)
==11809== by 0x431803: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:731)
==11809== by 0x432675: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1058)
==11809== by 0x40EF61: boost::unit_test::framework::init(boost::unit_test::test_suite* (*)(int, char**), int, char**) (framework.ipp:258)
==11809== by 0x41D740: boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int, char**), int, char**) (unit_test_main.ipp:169)
==11809== by 0x41DA70: main (unit_test_main.ipp:226)
==11809== Address 0x7FEFFEAB0 is on thread 1's stack
Running 1 test case...

*** No errors detected
==11809==
==11809== ERROR SUMMARY: 8 errors from 1 contexts (suppressed: 3 from 1)
==11809== malloc/free: in use at exit: 0 bytes in 0 blocks.
==11809== malloc/free: 200 allocs, 200 frees, 64,075 bytes allocated.
==11809== For counts of detected errors, rerun with: -v
==11809== All heap blocks were freed -- no leaks are possible.

I think if you would add
sigstk.ss_sp = 0;
sigstk.ss_size = 0;

in signal_handler::~signal_handler()

It will not complain about this. I know, it should not be necessary,
because it is disabling the signal stack, right?

Jarl

_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

Gennadiy Rozental

unread,
Jun 18, 2008, 11:01:24 PM6/18/08
to boost...@lists.boost.org
Jarl Friis <jarl <at> softace.dk> writes:
> I think if you would add
> sigstk.ss_sp = 0;
> sigstk.ss_size = 0;
>
> in signal_handler::~signal_handler()
>
> It will not complain about this.

Ok. I've added these lines.

> I know, it should not be necessary,
> because it is disabling the signal stack, right?

Yes. I believe so.

Gennadiy

Vladimir Prus

unread,
Jun 19, 2008, 3:56:35 AM6/19/08
to boost...@lists.boost.org
Gennadiy Rozental wrote:

> Jarl Friis <jarl <at> softace.dk> writes:
>> I think if you would add
>> sigstk.ss_sp = 0;
>> sigstk.ss_size = 0;
>>
>> in signal_handler::~signal_handler()
>>
>> It will not complain about this.
>
> Ok. I've added these lines.

Well, I think I've already fixed the issue on trunk, two weeks ago, in
a slightly more general way:

http://svn.boost.org/trac/boost/changeset/46159

>> I know, it should not be necessary,
>> because it is disabling the signal stack, right?
>
> Yes. I believe so.

But valgrind does not know that, so will complain if any data passed
to the kernel is uninitialized.

- Volodya

Gennadiy Rozental

unread,
Jun 19, 2008, 12:26:49 PM6/19/08
to boost...@lists.boost.org
Vladimir Prus <vladimir <at> codesourcery.com> writes:
> Well, I think I've already fixed the issue on trunk, two weeks ago, in
> a slightly more general way:

Thanks.

Gennadiy

Reply all
Reply to author
Forward
0 new messages