Segmentation fault arises on mips platform.

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Maybe it is impossible to reproduce to the problm if you don't have mips 
platform.Wish you have ways to reproduce it.
2.Just download my files in attchment.of course,you have to change something in 
Makefile.you can cross compile source file on x86,and run executable file on 
mips platform.of course,firstly,you should have google-perftools on mips 
platform.
3.sometimes the output is normal,while sometimes is unnormal with segmentation 
fault,so you have to run some times for reproducing the problem.

What is the expected output? What do you see instead?
expected output:
parameters: nthreads=8, niterations=60, nobjects=64, work=1, size=32
Timer elapsed = 0.002151 seconds.
sometimes expected output can be get,but sometimes not,the output is:
parameters: nthreads=8, niterations=60, nobjects=64, work=1, size=32
Segmentation fault 

What version of the product are you using? On what operating system?
1)google-perftools-1.7 
2)operating system using  uname -a
Linux (none) 2.6.27.7-Cavium-Octeon #2 SMP Fri Oct 29 13:47:54 CST 2010 mips64 
unknown
Please provide any additional information below.
On x86,the same program run normally using malloc or tcmalloc.On mips,the 
program run normally using malloc,while it is sometimes unormal with 
segmentation falut.
I used gdb to analyse the coredump ,sucn as:
 gdb -c core.25166  ./threadtest-cgz -d /mnt/tcmalloc/cgz/google-perftools-1.7/src
(gdb) bt
#0  0x000000555559ca78 in tcmalloc::ThreadCache::ReleaseToCentralCache 
(this=0x120274bf0, src=0x120274c68, cl=<value optimized out>, N=32)
    at src/linked_list.h:74
#1  0x000000555559cb08 in tcmalloc::ThreadCache::ListTooLong 
(this=0x55555c06b8, list=0x1202990c0, cl=0) at src/thread_cache.cc:181
#2  0x00000055555a2794 in tc_free (ptr=0x1202990c0) at src/thread_cache.h:349
#3  0x0000000120001640 in worker (arg=0x0) at threadtest.c:46
#4  0x00000055555eecfc in ?? () from /lib64/libpthread.so.0
analyse other coredump,Maybe get other information.

Original issue reported on code.google.com by sd.beiji...@gmail.com on 12 May 2011 at 9:36

Attachments:

• threadtest.cpp
• Makefile

[GoogleCodeExporter]

You are right, we don't have a mips platform to debug on, so you may have to 
look into this yourself with gdb or the like.

What happens when you run 'make test' in the perftools directory?  Do all 
unittests pass?

Original comment by csilv...@gmail.com on 12 May 2011 at 7:08

• Added labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

Hi,
I just run the program of tcmalloc_minimal_unittest ,two errors arisen
sometimes,analyse them using gdb ,the results  as follows:
1)Program terminated with signal 11, Segmentation fault.
[New process 5489]
[New process 5481]
[New process 5480]
[New process 5479]
[New process 5482]
[New process 5484]
[New process 5483]
[New process 5485]
[New process 5488]
[New process 5486]
[New process 5487]
#0  tcmalloc::NewSpan (p=1185509, len=6) at src/page_heap_allocator.h:61
61            free_list_ = *(reinterpret_cast<void**>(result));
(gdb) bt
#0  tcmalloc::NewSpan (p=1185509, len=6) at src/page_heap_allocator.h:61
#1  0x000000555559928c in tcmalloc::PageHeap::Split (this=0x55555c2570,
span=0x12002aec0, n=5) at src/page_heap.cc:147
#2  0x000000555559320c in do_memalign (align=32768, size=19685) at
src/tcmalloc.cc:1312
#3  0x00000055555a1dc4 in tc_posix_memalign (result_ptr=0x55563f4940,
align=<value optimized out>, size=19685) at src/tcmalloc.cc:1028
#4  0x0000000120009a60 in testing::TesterThread::Run (this=0x1203653c0) at
src/tests/tcmalloc_unittest.cc:272
#5  0x0000000120009b74 in RunFunctionInThreadWithId (ptr_to_fnid=0x1) at
src/tests/testutil.cc:173
#6  0x00000055555dfcfc in ?? () from /lib64/libpthread.so.0
2)Program terminated with signal 10, Bus error.
[New process 5271]
[New process 5275]
[New process 5276]
[New process 5272]
[New process 5274]
[New process 5273]
[New process 5277]
[New process 5279]
[New process 5278]
[New process 5270]
[New process 5269]
#0  tc_malloc (size=<value optimized out>) at src/linked_list.h:63
63        *list = SLL_Next(*list);
(gdb) bt
#0  tc_malloc (size=<value optimized out>) at src/linked_list.h:63
#1  0x0000000120008a98 in testing::TesterThread::Run (this=0x120365140) at
src/tests/tcmalloc_unittest.cc:280
#2  0x0000000120009b74 in RunFunctionInThreadWithId
(ptr_to_fnid=0x12027d808) at src/tests/testutil.cc:173
#3  0x00000055555dfcfc in ?? () from /lib64/libpthread.so.0
I am looking forward to your reply,Thank you very much!

Original comment by sd.beiji...@gmail.com on 13 May 2011 at 2:56

[GoogleCodeExporter]

This means memory corruption of some sort somewhere.  It could be anywhere, and 
due to anything.  Are you running the mips processor with big- or 
little-endianness?  A shot in the dark would be to play around with that.  More 
fruitfully, you might try configuring with optimization turned off and see if 
the tests pass then.  I'm afraid you'll have to try to debug this on your own.

Original comment by csilv...@gmail.com on 24 May 2011 at 4:31

[GoogleCodeExporter]

what are the differences between the spinlock achieved in google-perftools
and the default spinlock which we used to use in multi-threading program.Why
did you re-achieve spinlock?
the new one is faster than the defalut one ??

Original comment by sd.beiji...@gmail.com on 26 May 2011 at 8:16

[GoogleCodeExporter]

I coded one case which using the new spinlock or the defalut one.it appeared
that the defalut one is faster.

2011/5/26 Dwyane Wade <sd.beijing2008@gmail.com>

Original comment by sd.beiji...@gmail.com on 26 May 2011 at 8:18

[GoogleCodeExporter]

I don't undersatnd these last two questions.  What default spinlock are you 
referring to?  Also, what does this have to do with segfaults on mips?

Original comment by csilv...@gmail.com on 26 May 2011 at 8:31

[GoogleCodeExporter]

Sorry,Maybe I didn't descript the question clearly.The default spinlock i
referred to is what is realized in NPTL.If we need to use the spinlock,we
just need to inlucde "pthread.h".Now I doubt spinlock may have to do with
segfaluts on mips.So I want to know t he differences of these two spinlock?
Why you have to re-realize the spinlock which has been implemeted in NPTL?

Original comment by sd.beiji...@gmail.com on 27 May 2011 at 2:13

[GoogleCodeExporter]

} Now I doubt spinlock may have to do with segfaluts on mips.

OK, so let's move this discussion off this bug report.  Feel free to re-send 
your question to google-perftools@googlegroups.com.

Original comment by csilv...@gmail.com on 27 May 2011 at 3:29

[GoogleCodeExporter]

Original comment by csilv...@gmail.com on 18 Oct 2011 at 5:49

• Changed state: Invalid

[GoogleCodeExporter]

Hi, I'm working on a MIPS64(Octeon2) system, and I think I'm getting the same 
problem.
Can anyone tell me the status of this issue?

Original comment by ontop.st...@gmail.com on 4 Aug 2014 at 5:32

[GoogleCodeExporter]

This ticket is too old and likely long irrelevant.

Please open brand new ticket with all details of your case.

Original comment by alkondratenko on 4 Aug 2014 at 8:22