Closed GoogleCodeExporter closed 9 years ago
One test I know about, and is documented on the homepage at
code.google.com/p/google-perftools -- this is a failure of the
profiler_unittest.sh
that is (I think) due to a bug in how FreeBSD handles timer interrupts. As far
as I
can tell, the bug triggers in the unittest but not in real life. But I haven't
figured out the underlying cause yet.
But I don't see any other failures when testing on my freebsd machine. Can you
include full machine info, OS version, and the full output of running 'make
check'?
Original comment by csilv...@gmail.com
on 24 Jan 2010 at 10:52
} Can you include full machine info, OS version, and the full output of running
'make
check'?
I'm happy to look into this, but I'll really need this data to get started.
Original comment by csilv...@gmail.com
on 10 Mar 2010 at 6:56
This bug is about FreeBSD. Can you please open a new bug with your problem?
Original comment by csilv...@gmail.com
on 26 Apr 2010 at 10:57
Any more word on this? Without knowing what tests you're referring to, I'll
have to close this CannotReproduce.
Original comment by csilv...@gmail.com
on 7 Jun 2010 at 10:52
I am not sure why, but today there are 8 testcases fail on FreeBSD-8.0-STABLE:
FAIL: tcmalloc_minimal_unittest
FAIL: tcmalloc_minimal_debug_unittest
FAIL: tcmalloc_unittest
FAIL: tcmalloc_both_unittest
FAILED. Output from ./src/pprof --text
/usr/ports/devel/google-perftools/work/google-perftools-1.5/.libs/sampling_test
/tmp/sampling_test_dir/out.heap
FAIL: sampling_test.sh
FAIL: tcmalloc_debug_unittest
FAILED. Output from ./src/pprof --text
/usr/ports/devel/google-perftools/work/google-perftools-1.5/.libs/sampling_test
/tmp/sampling_test_dir/out.heap
FAIL: sampling_debug_test.sh
FAIL: tcmalloc_and_profiler_unittest
Original comment by yuriv...@yahoo.com
on 8 Jun 2010 at 5:29
6 out of 8 cases fail with Segmentation fault, which is likely new compared to
few months ago. The only thing that changes ins OS itself that got many
security updates.
Original comment by yuriv...@yahoo.com
on 8 Jun 2010 at 5:35
Unfortunately, I don't have any freebsd 8.0 machines to test on. I'll see if I
can rustle some up -- it may not be so easy.
Can you try building with
./configure CXXFLAGS=-g
? This turns off optimization. That might tell us something. Also, you can
try to run tcmalloc_minimal_unittest in gdb, perhaps, and provide a backtrace
of where it's crashing? That will tell *some* info, maybe it will be enough.
Original comment by csilv...@gmail.com
on 8 Jun 2010 at 7:08
Version 1.6 also fails 6 cases.
All with Segmentation fault.
tcmalloc_minimal_unittest tcmalloc_minimal_debug_unittest tcmalloc_unittest
tcmalloc_both_unittest tcmalloc_debug_unittest tcmalloc_and_profiler_unittest
FreeBSD 8.1-STABLE
Original comment by yuriv...@yahoo.com
on 7 Aug 2010 at 7:13
Were you able to do any of the tests I mentioned in comment 8?
} Can you try building with
} ./configure CXXFLAGS=-g
} ? This turns off optimization. That might tell us something. Also, you can
try to
} run tcmalloc_minimal_unittest in gdb, perhaps, and provide a backtrace of
where it's
} crashing? That will tell *some* info, maybe it will be enough.
Weird that sampling_test is now passing. I wonder what changed there.
Original comment by csilv...@gmail.com
on 8 Aug 2010 at 2:40
For version 1.6:
All tests pass on amd64.
On i386 these 6 fail, same with and without -g flag (like you suggested):
FAIL: tcmalloc_minimal_unittest
FAIL: tcmalloc_minimal_debug_unittest
FAIL: tcmalloc_unittest
FAIL: tcmalloc_both_unittest
FAIL: tcmalloc_debug_unittest
FAIL: tcmalloc_and_profiler_unittest
I will try to get stack like you suggested later.
Original comment by yuriv...@yahoo.com
on 1 Sep 2010 at 9:15
Please find the backtrace of tcmalloc_minimal_unittest (version 1,6) on
FreeBSD-i386:
--- backtrace ---
<skipped>
Testing alignment of malloc(16385)
Testing alignment of malloc(32767)
Testing alignment of malloc(32768)
Testing alignment of malloc(32769)
Testing calloc
Testing realloc
Testing operator new(nothrow).
tcmalloc: large alloc 4294967296 bytes == 0x0 @
tcmalloc: large alloc 4294967296 bytes == 0x0 @
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 80d5000 (LWP 100198)]
get_cie_encoding () at unwind-dw2-fde.c:273
273 unwind-dw2-fde.c: No such file or directory.
in unwind-dw2-fde.c
Current language: auto; currently c
(gdb) bt
#0 get_cie_encoding () at unwind-dw2-fde.c:273
#1 0x33dc986c in classify_object_over_fdes () at unwind-dw2-fde.c:603
#2 0x33dc9fc4 in search_object () at unwind-dw2-fde.c:731
#3 0x33dca62e in _Unwind_Find_FDE () at unwind-dw2-fde.c:985
#4 0x33dc87ff in uw_frame_state_for () at unwind-dw2.c:136
#5 0x33dc8b55 in uw_init_context_1 () at unwind-dw2.c:1412
#6 0x33dc91a4 in _Unwind_RaiseException () at unwind.inc:92
#7 0x33d3b41d in __cxa_throw () from /usr/lib/libstdc++.so.6
#8 0x0804c634 in TestNewHandler () at src/tests/tcmalloc_unittest.cc:594
#9 0x33ca3ec9 in cpp_alloc (size=4294967295, nothrow=true) at
src/tcmalloc.cc:1267
#10 0x33cb218f in tc_new_nothrow (size=4294967295) at src/tcmalloc.cc:1406
#11 0x0804a7c2 in TestOneNothrowNew (func=0x8049968 <operator new(unsigned int,
std::nothrow_t const&)>) at src/tests/tcmalloc_unittest.cc:657
#12 0x0804ae31 in TestNothrowNew (func=0x8049968 <operator new(unsigned int,
std::nothrow_t const&)>) at src/tests/tcmalloc_unittest.cc:676
#13 0x0804c1ec in RunAllTests (argc=1, argv=0xbfbfe744) at
src/tests/tcmalloc_unittest.cc:1175
#14 0x0804c4b2 in main (argc=Error accessing memory address 0xd9dcc83d: Bad
address.
) at src/tests/tcmalloc_unittest.cc:1230
Original comment by yuriv...@yahoo.com
on 1 Sep 2010 at 9:30
Glad to hear they all pass on x86_64!
Interesting crash on i386 (usually the easier platform!) Do you happen to have
the libc source code available, and can see what unwind-dw2-fde.c:273 (and
nearby code) looks like? I found an old version online, but I'm sure the
current version is different.
One thing to check is if get_cie_encoding allocates memory (unlikely, based on
the name, but you never know...) Another is if we can figure out what the
segfault value is. Maybe there's corruption somewhere somehow? It's hard to
guess.
Original comment by csilv...@gmail.com
on 2 Sep 2010 at 12:19
I've not heard any reports of this from other freebsd users, and can't
reproduce it on my local freebsd 8.1 system -- to be sure, it's a 64-bit
system, which you said was working ok for you, which might explain it. But I'm
going to have to close this CannotReproduce. If you can figure out what's
going on locally, feel free to reopen.
Original comment by csilv...@gmail.com
on 31 Aug 2011 at 10:27
Original issue reported on code.google.com by
y...@tsoft.com
on 23 Jan 2010 at 9:53