Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2

[Nat Sloss <nathanialsloss%yahoo.com.au@localhost>]

The following reply was made to PR lib/48324; it has been noted by GNATS.

From: Nat Sloss <nathanialsloss%yahoo.com.au@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 
2
Date: Mon, 21 Oct 2013 00:02:29 +1100

 Hi.
 >  It would be super helpfull if you could create a minimalistic set of
 >  "hello world" style shared libs and main application reproducing the
 >  failure from sources, which we could use to verify a fix and as base
 >  for a later regression test.
 
 Unfortunately the test I'm trying to writ succeeds and I've just created a 
 sourceforge account and have been added to pkgsrc-wip.
 
 I have an updated version of calligra which I'm about three days away from 
 committing of which calligra words and calligraauthor exhibit the failure.
 
 So I can only supply back traces and information from gdb until I commit the 
 package and others can test it.
 
 However I have found something interesting from the back trace of the hung 
 process.
 
 The backtrace is as follows:
 
 
 #0  0xbb7f904b in _rtld_tls_allocate_locked ()
     at /home/build/NetBSD-6.1_source_tree/usr/src/libexec/ld.elf_so/tls.c:148
 #1  0xbb7f9088 in _rtld_tls_allocate ()
     at /home/build/NetBSD-6.1_source_tree/usr/src/libexec/ld.elf_so/tls.c:162
 #2  0xb8c4c799 in pthread_create (thread=0xb3272cb4, attr=0xbf7fda48,
     startfunc=0xb9521342 <QThreadPrivate::start(void*)>, arg=0xb327bf60)
     at /home/build/NetBSD-6.1_source_tree/usr/src/lib/libpthread/pthread.c:430
 #3  0xb9521780 in QThread::start (this=0xb327bf60,
     priority=QThread::InheritPriority) at thread/qthread_unix.cpp:640
 #4  0xb9603edc in QKqueueFileSystemWatcherEngine::addPaths (this=0xb327bf60,
     paths=..., files=0xb32922b8, directories=0xb32922bc)
     at io/qfilesystemwatcher_kqueue.cpp:196
 #5  0xb95f4574 in QFileSystemWatcher::addPaths (this=0xb73ff790, paths=...)
     at io/qfilesystemwatcher.cpp:545
 #6  0xb95f4fc3 in QFileSystemWatcher::addPath (this=0xb73ff790, path=...)
     at io/qfilesystemwatcher.cpp:486
 #7  0xb990f15a in KDirWatchPrivate::useQFSWatch (this=0xb739b600, 
 e=0xb329a794)
     
 at 
/home/packages/2013Q2/pkgsrc/x11/kdelibs4/work/kdelibs-4.10.3/kdecore/io/kdirwatch.cpp:717
 #8  0xb990e1ff in KDirWatchPrivate::addWatch (this=0xb739b600, e=0xb329a794)
     
 at 
/home/packages/2013Q2/pkgsrc/x11/kdelibs4/work/kdelibs-4.10.3/kdecore/io/kdirwatch.cpp:934
 
 What is interesting is pthread.c:430 revision 1.125.4.3
 There is a call to rtld_tls_allocate without a proceeding call to 
 _rtld_tls_offset_allocate and i know that the tls_static_space is the minimum 
 64 bytes and the tlsoffset is zero.  So would a call to tls_allocate_offset 
 fix the problem.
 
 Would that be appropriate?
 
 And to successfully create an example of the failure I'd have to know under 
 what circumstances creating a thread that would then load tls data from a 
 shared library that was not previously allocated/initialized.
 
 Regards,
 
 Nat.