Re: [Bug-tar] Small bug in tar-1.29

[Jack Howarth]

On Tue, Sep 06, 2016 at 04:12:12PM -0400, Jack Howarth wrote:
> On Tue, Sep 06, 2016 at 08:12:05PM +0100, Ralph Corderoy wrote:
> > Hi Jack,
> > 
> > > > gnutar: Child died with signal 11
> > ...
> > > stop reason = signal SIGPIPE
> > 
> > SIGPIPE is 13.  We want 11, SIGSEGV.  Perhaps a "c" or two for continue
> > will have the debugger carry on until the SEGV bites.
> 
> $ ulimit -c unlimited
> $ gnutar -zcvf test_data.tar.gz test_data 
> test_data/
> test_data/.noe.tbl.swp
> test_data/dihedral.tbl
> test_data/file.nam
> test_data/io.mc
> test_data/noe.tbl
> gnutar: test_data.tar.gz: Cannot write: Broken pipe
> gnutar: Child died with signal 11
> gnutar: Error is not recoverable: exiting now
> $ lldb -c /cores/core.21601 `which gnutar`
> (lldb) target create "/opt/local/bin/gnutar" --core "/cores/core.21601"
> warning: (x86_64) /cores/core.21601 load command 84 LC_SEGMENT_64 has a 
> fileoff + filesize (0x296fe000) that extends beyond the end of the file 
> (0x296fd000), the segment will be truncated to match
> Core file '/cores/core.21601' (x86_64) was loaded.
> (lldb) bt
> * thread #1: tid = 0x0000, 0x00007fff94ebb6d7 
> libdispatch.dylib`_dispatch_queue_push_queue + 463, stop reason = signal 
> SIGSTOP
>   * frame #0: 0x00007fff94ebb6d7 libdispatch.dylib`_dispatch_queue_push_queue 
> + 463
>     frame #1: 0x00007fff7478c4d0 libdispatch.dylib`_OS_dispatch_mach_vtable + 
> 48
>     frame #2: 0x00007fff94eb9b06 
> libdispatch.dylib`_dispatch_queue_wakeup_with_qos_slow + 126
>     frame #3: 0x00007fff94ec013f libdispatch.dylib`_dispatch_mach_msg_send + 
> 1952
>     frame #4: 0x00007fff94ebf8dc libdispatch.dylib`dispatch_mach_send + 262
>     frame #5: 0x00007fff89448fc9 
> libxpc.dylib`xpc_connection_send_message_with_reply + 131
>     frame #6: 0x00007fff8e31ebdf CoreFoundation`__66-[CFPrefsSearchListSource 
> generationCountFromListOfSources:count:]_block_invoke_2 + 143
>     frame #7: 0x00007fff8e31ea0d CoreFoundation`_CFPrefsWithDaemonConnection 
> + 381
>     frame #8: 0x00007fff8e31db96 CoreFoundation`__66-[CFPrefsSearchListSource 
> generationCountFromListOfSources:count:]_block_invoke + 150
>     frame #9: 0x00007fff8e31d933 CoreFoundation`-[CFPrefsSearchListSource 
> generationCountFromListOfSources:count:] + 179
>     frame #10: 0x00007fff8e31d214 CoreFoundation`-[CFPrefsSearchListSource 
> alreadylocked_copyDictionary] + 324
>     frame #11: 0x00007fff8e31ce5c CoreFoundation`-[CFPrefsSearchListSource 
> alreadylocked_copyValueForKey:] + 60
>     frame #12: 0x00007fff8e31cdec 
> CoreFoundation`___CFPreferencesCopyAppValueWithContainer_block_invoke + 60
>     frame #13: 0x00007fff8e314b10 CoreFoundation`+[CFPrefsSearchListSource 
> withSearchListForIdentifier:container:perform:] + 608
>     frame #14: 0x00007fff8e314867 
> CoreFoundation`_CFPreferencesCopyAppValueWithContainer + 183
>     frame #15: 0x00000001021a6538 
> libintl.8.dylib`_nl_language_preferences_default + 70
>     frame #16: 0x00000001021a462f libintl.8.dylib`libintl_dcigettext + 667
>     frame #17: 0x00000001021491f2 gnutar`sys_child_open_for_compress + 125
>     frame #18: 0x000000010213011f gnutar`open_archive + 603
>     frame #19: 0x00000001021355ab gnutar`create_archive + 67
>     frame #20: 0x000000010214b494 gnutar`main + 3510
>     frame #21: 0x00007fff895605ad libdyld.dylib`start + 1
>     frame #22: 0x00007fff895605ad libdyld.dylib`start + 1
> (lldb)
> 

I also confirmed that this issue doesn't exist in tar 1.28. The fact that the 
backtrace for the crash seems to go
through CoreFoundation reinforces my suspicion the problem is a thread not 
being locked properly. We had a
problem with random failures in make 4.0/4.1 when executed within the fink 
packaging manager that could be 
suppressed by building make with '--disable-nls' to avoid the threading in the 
CoreFoundation framework.
Upstream fixed this in make 4.2.1 with....

http://git.savannah.gnu.org/cgit/make.git/commit/?id=85c788572d054bc2c41b84007875edbd37ad3ed5

http://savannah.gnu.org/bugs/?46261#comment12

by using pselect() to lock the thread. Perhaps something similar needs to be 
done for the xpipe calls in tar 1.29?

> 
> > 
> > -- 
> > Cheers, Ralph.
> > https://plus.google.com/+RalphCorderoy