- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Attempt to free unallocated or already freed o...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-06-2013 06:29 AM
11-06-2013 06:29 AM
My multithreaded program in one of its threads calls fork() and then does execle(). When I use libc malloc and free everything iis OK. When I use libRTC in order to check possible invalid memory allocations and deallocations I see this report:
>more has_serverd.1748.mem
-----------------------------------------
Attempt to free unallocated or already freed object at 0x9fffffffbdca13b0
Current context is:
(0) 0xc00000000bbae760 print_stack_trace_to_log_file + 0x2c0 at ../../../Src/gnu/gdb/infrtc.c:1557 [/opt/langtools/lib/hpux64/librtc.so]
(1) 0xc00000000bbb2640 __rtc_event + 0x1c0 at ../../../Src/gnu/gdb/infrtc.c:2177 [/opt/langtools/lib/hpux64/librtc.so]
(2) 0xc00000000bbba2b0 rtc_record_free + 0x500 at ../../../Src/gnu/gdb/infrtc.c:3969 [/opt/langtools/lib/hpux64/librtc.so]
(3) 0xc00000000bbbcd20 free + 0x200 at ../../../Src/gnu/gdb/infrtc.c:4484 [/opt/langtools/lib/hpux64/librtc.so]
(4) 0xc000000000203570 __fork_cleanup_channel + 0x90 at /ux/core/libs/threadslibs/src/common/pthreads/sleep.c:3684 [/lib/hpux64/libpthread.so.1]
(5) 0xc000000000157d30 __pthread_fork_child_cleanup + 0x370 at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:8018 [/lib/hpux64/libpthread.so.1]
(6) 0xc000000000173010 __pthread_fork + 0x430 at /ux/core/libs/threadslibs/src/common/pthreads/fork.c:1056 [/lib/hpux64/libpthread.so.1]
(7) 0xc00000000055bd90 _fork + 0xd0 [/lib/hpux64/libc.so.1]
(8) 0xc0000000355cbf90 _ZN13Cache_Storage22CouchbaseLoaderStarter5startEv + 0x30 at ucouchbasestorage.cpp:314 [/import/home/sergey.kurenkov/has.051.02.hpux.bc/libexec/cache.so]
(9) 0xc000000035601c30 _ZN8selfcare11CCacheQuery9do_reopenERN6oracle14oracle_connectERKSbIwSt20encoding_char_traitsIwESaIwEERN5boost6tuples5tupleIRKNSA_8hash_mapIS7_S7_NSA_4hashIS7_EEEERKSt8multimapIS7_S7_S
t4lessIS7_ESaISt4pairIS8_S7_EEERSG_RN11db_id_types4baseIxLj22EEERSP_SS_SI_SI_SR_NSB_9null_typeEEERKNS_16operation_args_tEb + 0x1f40 at ucachequery.cpp:923 [/import/home/sergey.kurenkov/has.051.02.hpux.bc/libe
xec/cache.so]
(10) 0xc000000035608350 _ZN8selfcare11CCacheQuery7do_initERN6oracle14oracle_connectERKSbIwSt20encoding_char_traitsIwESaIwEERN5boost6tuples5tupleIRKNSA_8hash_mapIS7_S7_NSA_4hashIS7_EEEERKSt8multimapIS7_S7_St4
lessIS7_ESaISt4pairIS8_S7_EEERSG_RN11db_id_types4baseIxLj22EEERSP_SS_SI_SI_SR_NSB_9null_typeEEERKNS_16operation_args_tEb + 0x330 at ucachequery.cpp:291 [/import/home/sergey.kurenkov/has.051.02.hpux.bc/libexec
/cache.so]
(11) 0xc00000003563b3e0 _ZN5cache12cache_worker10do_executeEv + 0xf30 at cache_threads.cpp:280 [/import/home/sergey.kurenkov/has.051.02.hpux.bc/libexec/cache.so]
(12) 0xc00000003563c9d0 _ZN5cache12cache_worker7executeEv + 0x200 at cache_threads.cpp:359 [/import/home/sergey.kurenkov/has.051.02.hpux.bc/libexec/cache.so]
(13) 0xc000000032a38690 _ZN7threads11thread_procEPv + 0x1c0 [./libhas_common.so]
(14) 0xc00000000013fb20 __pthread_bound_body + 0x190 at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4875 [/lib/hpux64/libpthread.so.1]
I've got a question. The pointer 0x9fffffffbdca13b0 that is passed to free() seems does not belong to heap and is not allocated inside my program. Where does it come from?
Moreover I know that if I do vfork() instead of fork() there is no coredump. So is it related to pthread_atfork()? However I do not call pthread_atfork() in my code. There are only two calls to it and they come from __libc_startup()
(gdb) bt
#0 pthread_atfork ()
at /ux/core/libs/threadslibs/src/common/pthreads/fork.c:234
#1 0x9fffffffb4469310:0 in __thread_atfork ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/threads/wrappers1.c:672
#2 0x9fffffffb4467000:0 in __libc_init ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/threads/libc_init.c:739
#3 0x9fffffffbf2a7080:0 in __hp__init_libc ()
at /ux/core/libs/threadslibs/src/common/pthreads/tepv.c:86
#4 0x9fffffffbf2bb270:0 in __pthread_startup ()
at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:1441
#5 0x9fffffffb42a73e0:0 in __libc_startup ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/csu/init_libc.c:153
#6 0x9fffffffbf7705d0:0 in EM_mark_BOS+0x50 () from /usr/lib/hpux64/dld.so
(gdb) bt
#0 pthread_atfork ()
at /ux/core/libs/threadslibs/src/common/pthreads/fork.c:234
#1 0x9fffffffb4469310:0 in __thread_atfork ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/threads/wrappers1.c:672
#2 0x9fffffffbf181b40:0 in libdl_init () at Libdl/libdl.c:76
#3 0x9fffffffb42a7420:0 in __libc_startup ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/csu/init_libc.c:159
#4 0x9fffffffbf7705d0:0 in EM_mark_BOS+0x50 () from /usr/lib/hpux64/dld.so
How to fix this invalid free() that libRTC reports inside fork()? Or is possible that it is a problem in libpthread.so?
And finally. librtc seems to cause a coredump in another place:
Core was generated by `has_serverd'.
Program terminated with signal 11, Segmentation fault.
SEGV_MAPERR - Address not mapped to object
#0 mark (first=<not available>,
last=<not available>, leak_detection=<not available>,
internal_gc=<not available>, location=PROCESS_STACK)
at ../../../Src/gnu/gdb/infrtc.c:7667
7667 ../../../Src/gnu/gdb/infrtc.c: No such file or directory.
in ../../../Src/gnu/gdb/infrtc.c
Breakpoint 1 at 0xc000000000171840:2: file /ux/core/libs/threadslibs/src/common/pthreads/fork.c, line 234 from /lib/hpux64/libpthread.so.1.
(gdb) bt
#0 mark (first=<not available>, last=<not available>,
leak_detection=<not available>, internal_gc=<not available>,
location=PROCESS_STACK) at ../../../Src/gnu/gdb/infrtc.c:7667
#1 0xc00000000bbcca60:0 in rtc_leaks_or_dangling_info_common (
leak_detection=true, internal_gc=false)
at ../../../Src/gnu/gdb/infrtc.c:8085
#2 0xc00000000bbaa8b0:0 in __rtc_leaks_info ()
at ../../../Src/gnu/gdb/infrtc.c:8182
#3 0xc00000000bbdeb90:0 in produce_memory_report ()
at ../../../Src/gnu/gdb/infrtc.c:11016
#4 0xc00000000bbc65e0:0 in rtc_leak_analyze ()
at ../../../Src/gnu/gdb/infrtc.c:9549
#5 0xc0000000005689f0:0 in __thread_once ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/threads/wrappers1.c:467
#6 0xc00000000bbc5dd0:0 in _exit (status=0)
at ../../../Src/gnu/gdb/infrtc.c:6758
#7 0xc0000000355cdba0:0 in Cache_Storage::CouchbaseLoaderStarter::start (
this=0x9fffffff5e66e4a8) at cache_source/ucouchbasestorage.cpp:374
#8 0xc000000035601c30:0 in selfcare::CCacheQuery::do_reopen (
this=<not available>, conn=<not available>, aSQL=<not available>,
tuple_vars=<not available>, args=@0x6000000002e64688, is_strict=false)
at cache_source/ucachequery.cpp:923
#9 0xc000000035608350:0 in selfcare::CCacheQuery::do_init (
this=0x600000000987c690, conn=@0x600000000991be00,
aSQL=@0x6000000002e646b0, tuple_vars=@0x6000000002e64640,
args=@0x6000000002e64688, is_strict=false)
at cache_source/ucachequery.cpp:265
#10 0xc00000003563b3e0:0 in cache::cache_worker::do_execute (
this=0x6000000000222c90) at cache_source/cache_threads.cpp:280
#11 0xc00000003563c9d0:0 in cache::cache_worker::execute (
this=0x6000000000222c90) at cache_source/cache_threads.cpp:359
warning: No unwind information found.
Skipping this library /import/home/sergey.kurenkov/has.051.02.hpux.bc/./lib/libxalanMsg.so.
#12 0xc000000032a38690:0 in threads::thread_proc(void*)+0x1c0 ()
from ./libhas_common.so
#13 0xc00000000013fb20:0 in __pthread_bound_body ()
at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4875
(gdb)
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-06-2013 11:03 PM
11-06-2013 11:03 PM
Re: Attempt to free unallocated or already freed object inside fork() in a multithreaded program
>The pointer 0x9fffffffbdca13b0 that is passed to free() seems does not belong to heap and is not allocated inside my program. Where does it come from?
It looks like a stack address or possibly a mmap region.
You might be able to use the following for more details:
(gdb) info sym 0x9fffffffbdca13b0
>So is it related to pthread_atfork()? I do not call pthread_atfork
Very possibly. It doesn't matter if you call it or not.
>Or is possible that it is a problem in libpthread.so?
It sure looks like it. Please contact the Response Center and file a bug.
>librtc seems to cause a coredump in another place:
Do you have a thread stackoverflow?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-06-2013 11:40 PM
11-06-2013 11:40 PM
Re: Attempt to free unallocated or already freed object inside fork() in a multithreaded program
>>librtc seems to cause a coredump in another place:
> Do you have a thread stackoverflow?
For this thread:
(gdb) f 13
#13 0xc00000000013fb20:0 in __pthread_bound_body ()
at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4875
4875 /ux/core/libs/threadslibs/src/common/pthreads/pthread.c: No such file or directory.
in /ux/core/libs/threadslibs/src/common/pthreads/pthread.c
(gdb) p/x $sp
$2 = 0x9fffffff5e670ff0
(gdb) f 0
#0 mark (first=<not available>, last=<not available>,
leak_detection=<not available>, internal_gc=<not available>,
location=PROCESS_STACK) at ../../../Src/gnu/gdb/infrtc.c:7667
7667 ../../../Src/gnu/gdb/infrtc.c: No such file or directory.
in ../../../Src/gnu/gdb/infrtc.c
(gdb) p/x $sp
$3 = 0x9fffffff5e66d7f0
(gdb) p $2-$3
$4 = 14336
14336 is not a lot so I guess it is not a stackoverflow.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2013 12:19 AM
11-07-2013 12:19 AM
Re: Attempt to free unallocated or already freed object inside fork() in a multithreaded program
> You might be able to use the following for more details:
> (gdb) info sym 0x9fffffffbdca13b0
There is core file for this process so I loaded it in gdb:
(gdb) info sym 0x9fffffffbdca13b0
No symbol matches 0x9fffffffbdca13b0.
And judging from "info shared" this address does not belong to any library.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2013 01:11 PM
11-07-2013 01:11 PM
Re: Attempt to free unallocated or already freed object inside fork() in a multithreaded program
>(gdb) p/x $sp
There are two stacks for each thread. You also need to compute the $bsp difference.
>14336 is not a lot
Yes, doesn't seem like a lot.
You need to look at the machine code for frame 0:
(gdb) info reg
(gdb) disas
And see what instruction and what register (address) is being used to store/load.
>There is core file for this process so I loaded it in gdb:
>And judging from "info shared"
Then it is in a stack or mmap region.
Try using: elfdump -S -o core
Then see which region has 0x9fffffffbdca13b0.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-07-2013 10:33 PM - edited 11-07-2013 10:43 PM
11-07-2013 10:33 PM - edited 11-07-2013 10:43 PM
Re: Attempt to free unallocated or already freed object inside fork() in a multithreaded program
Dennis, thanks for your response.
> There are two stacks for each thread. You also need to compute the $bsp difference.
> Try using: elfdump -S -o core
Well, I will do these steps later if it is necessary. But first, I have created a test program and it shows these two errors.
I have three HP-UX 11.31 servers and on all of them I can reproduce them regularly but not always.
Could you please check this test on an HP-UX server?
Actually in the test fork() is just called:
pid_t pid;
if((pid = fork()) < 0) {
printf("an error occurred while forking\n");
}
else if(pid == 0) {
if (verbose) {
printf("being forked, pid: %d, thread: %d \n", getpid(), pthread_self());
}
execv("./invalid_program_name",NULL);
_exit(0);
}
else {
if (verbose) {
printf("forked, pid: %d, thread: %d \n", getpid(), pthread_self());
}
}
This is how I build a test:
aCC -mt +DD64 -g test_pthread_key_2.cpp -o test_pthread_key_2.acc
This is my rtcconfig:
check_heap=on
check_leaks=on
set heap-check on
set heap-check frame-count 14
This is how I run it:
BATCH_RTC=on LD_PRELOAD=/opt/langtools/lib/hpux64/librtc.so ./test_pthread_key_2.acc 1 10 2 0
And after running the test sometimes I've got no reports about invalid calls to free(), sometimes I've up to five or six reports like this:
>more test_pthread_key_2.acc.3131.mem
-----------------------------------------
Attempt to free unallocated or already freed object at 0x9fffffffbf6993b0
Current context is:
(0) 0xc00000000bbae760 print_stack_trace_to_log_file + 0x2c0 at ../../../Src/gnu/gdb/infrtc.c:1557 [/opt/langtools/lib/hpux64/librtc.so]
(1) 0xc00000000bbb2640 __rtc_event + 0x1c0 at ../../../Src/gnu/gdb/infrtc.c:2177 [/opt/langtools/lib/hpux64/librtc.so]
(2) 0xc00000000bbba2b0 rtc_record_free + 0x500 at ../../../Src/gnu/gdb/infrtc.c:3969 [/opt/langtools/lib/hpux64/librtc.so]
(3) 0xc00000000bbbcd20 free + 0x200 at ../../../Src/gnu/gdb/infrtc.c:4484 [/opt/langtools/lib/hpux64/librtc.so]
(4) 0xc0000000001375e0 __pthread_alloc + 0x2a80 at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:3576 [/usr/lib/hpux64/libpthread.so.1]
(5) 0xc0000000001365e0 __pthread_alloc + 0x1a80 at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:3473 [/usr/lib/hpux64/libpthread.so.1]
(6) 0xc000000000157d70 __pthread_fork_child_cleanup + 0x3b0 at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:8018 [/usr/lib/hpux64/libpthread.so.1]
(7) 0xc000000000173010 __pthread_fork + 0x430 at /ux/core/libs/threadslibs/src/common/pthreads/fork.c:1056 [/usr/lib/hpux64/libpthread.so.1]
(8) 0xc00000000055bd90 _fork + 0xd0 [/usr/lib/hpux64/libc.so.1]
(9) 0x40000000000020b0 _Z10threadfuncPv + 0x390 at test_pthread_key_2.cpp:32 [./test_pthread_key_2.acc]
(10) 0xc00000000013fb20 __pthread_bound_body + 0x190 at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4875 [/usr/lib/hpux64/libpthread.so.1]
And I always get core files after the test with backtrace like this:
host: srv2-bl870c-02, OS: HP-UX B.11.31>gdb ./test_pthread_key_2.acc core.3131
HP gdb 6.1 for HP Itanium (32 or 64 bit) and target HP-UX 11iv2 and 11iv3.
Copyright 1986 - 2009 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 6.1 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
Core was generated by `test_pthread_key_2.acc'.
Program terminated with signal 11, Segmentation fault.
SEGV_MAPERR - Address not mapped to object
#0 mark (first=<not available>, last=<not available>,
leak_detection=<not available>, internal_gc=<not available>,
location=PROCESS_STACK) at ../../../Src/gnu/gdb/infrtc.c:7667
7667 ../../../Src/gnu/gdb/infrtc.c: No such file or directory.
in ../../../Src/gnu/gdb/infrtc.c
(gdb) bt
#0 mark (first=<not available>, last=<not available>,
leak_detection=<not available>, internal_gc=<not available>,
location=PROCESS_STACK) at ../../../Src/gnu/gdb/infrtc.c:7667
#1 0xc00000000bbcca60:0 in rtc_leaks_or_dangling_info_common (
leak_detection=true, internal_gc=false)
at ../../../Src/gnu/gdb/infrtc.c:8085
#2 0xc00000000bbaa8b0:0 in __rtc_leaks_info ()
at ../../../Src/gnu/gdb/infrtc.c:8182
#3 0xc00000000bbdeb90:0 in produce_memory_report ()
at ../../../Src/gnu/gdb/infrtc.c:11016
#4 0xc00000000bbc65e0:0 in rtc_leak_analyze ()
at ../../../Src/gnu/gdb/infrtc.c:9549
#5 0xc0000000005689f0:0 in __thread_once+0xf0 ()
from /usr/lib/hpux64/libc.so.1
#6 0xc00000000bbc5dd0:0 in _exit (status=0)
at ../../../Src/gnu/gdb/infrtc.c:6758
#7 0x40000000000022c0:0 in threadfunc (parm=0x0) at test_pthread_key_2.cpp:40
#8 0xc00000000013fb20:0 in __pthread_bound_body+0x190 ()
from /usr/lib/hpux64/libpthread.so.1
Current language: auto; currently c
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-08-2013 05:54 AM
11-08-2013 05:54 AM
Re: Attempt to free unallocated or already freed object inside fork() in a multithreaded program
>sometimes I've got no reports about invalid calls to free(), sometimes I've up to five or six reports like this:
Ok, I get something like that.
>And I always get core files after the test with backtrace like this:
I haven't got any of those.
Using tusc, the bad address to free seems to be allocated here in this mmap:
[29949] sigsetreturn(NULL, 0x6211988, 48640) ............. = 0
[29949] getpid() ......................................... = 29949 (29948)
[29949] sysconf(_SC_THREAD_THREADS_MAX) .................. = 3000
[29949] sysconf(_SC_THREAD_KEYS_MAX) ..................... = 256
[29949] mmap(NULL, 18008, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x9fffffffbd694000
[29949] sysconf(_SC_THREAD_STACK_MIN) .................... = 4096
[29949] mpctl(MPC_GETNUMSPUS, 0, 0) ...................... = 4
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-27-2014 12:46 AM - edited 02-27-2014 01:22 AM
02-27-2014 12:46 AM - edited 02-27-2014 01:22 AM
Re: Attempt to free unallocated or already freed object inside fork() in a multithreaded program
>>Or is possible that it is a problem in libpthread.so?
>It sure looks like it. Please contact the Response Center and file a bug.
So I have contacted the Response Center. They do not want to fix what seems to be undefined behaviour in their code (a pointer passed in function free() does not match a pointer earlier returned by malloc()). Instead I was told to erase mem files with cron. What a silly advice! Why each HP customer who uses libRTC should organize erasing mem-files produced by libRCT in this situation? Why not fix the undefined behavior in HP libpthread.so?
This is an email from HP:
From: Venkatachalam, Subramanian (BCS)
Sent: 26 февраля 2014 г. 12:16
To: Schigolev, Sergei
Subject: RE: BL870c libpthread.so problem case 4716260826
Sergei,
As there’s nothing new on the .mem files you provided – given that your abort is worked around I do not intend to keep this case open for more.
The number of .mem files can be removed by setting a cron job, looking for this current pattern.
Regards,
Subbu
HP Technology Services - BCS (HP-UX)
Hewlett-Packard
Working Hours: Mon to Fri 1230 hrs - 2130 hrs IST, GMT+5:30
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-27-2014 01:49 AM - edited 02-27-2014 01:56 AM
02-27-2014 01:49 AM - edited 02-27-2014 01:56 AM
Re: Attempt to free unallocated or already freed object inside fork() in a multithreaded program
>They do not want to fix what seems to be undefined behaviour in their code
I would suggest that they just file the bug and let R&D look at it. Perhaps there is something wrong with librtc and not libpthread?
At least if it is filed, it's in the bug database.
>Why each HP customer who uses librtc should organize erasing mem-files produced by librtc in this situation?
Well that solution only is useful if that's the only error in the file. ;-)
And those files are piling up.
>Why not fix the undefined behavior in HP libpthread.so?
Because you have to figure it out? ;-)
And everything seems to work unless you're also using librtc.
Do you have a way to duplicate the problem without using librtc by monitoring the values sent to free in your test case?
I was able to track it down to a mmap region but not what pointer.
But it would be lots easier for R&D to just look at it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-27-2014 01:55 AM - edited 02-27-2014 02:11 AM
02-27-2014 01:55 AM - edited 02-27-2014 02:11 AM
Re: Attempt to free unallocated or already freed object inside fork() in a multithreaded program
> I would suggest that they just file the bug and let R&D look at it.
This is a quote from HP letter I have attached:
I do not intend to keep this case open for more
>Perhaps there is something wrong with librtc and not libpthread?
I doubt. TCMalloc which also handles malloc() and free() reports me the same problem in this situation (invalid pointer passed to free() that had not been allocated earlier on by malloc()).