Bug#892272:

[Michael Jerris]

confirmed steps to reproduce the issue in the simplest way:

# ulimit -s 240 && openmpt123
Segmentation fault

Bug#892272:

[Michael Jerris]

The problem appears to be a large stack allocation in a static initializer when 
using constrained stack sizes.  This issue appears to be fixed in upstream 
openmpt, we are testing a back port of this patch now to confirm.  it appears 
the optimizer changes this from a stack allocation at -O3, but the explicit 
change is a better fix.

Bug#892272:

[Michael Jerris]

Confirmed its the same linking to JUST libopenmpt, without libavformat

Bug#892272: libavformat/libopenmpt failure on dlopen

[Michael Jerris]

I’m still working on a complete stand alone example but the way to reproduce 
this is to dlopen a module that is linked to libavformat.  It does not require 
any code at all related to libavformat to be executed at all, or any includes 
to libavformat, or anything at all related to apt, just the linking, then 
dlopen of that so

#0  0x7fd8315fdca2 in ?? () from /usr/lib/x86_64-linux-gnu/libopenmpt.so.0
#1  0x7fd87d8b08aa in call_init (l=, argc=argc@entry=2, 
argv=argv@entry=0x7ffc0cfd1b58, env=env@entry=0x7ffc0cfd1b70) at dl-init.c:72
#2  0x7fd87d8b09bb in call_init (env=0x7ffc0cfd1b70, argv=0x7ffc0cfd1b58, 
argc=2, l=) at dl-init.c:30
#3  _dl_init (main_map=main_map@entry=0x561842c5b320, argc=2, 
argv=0x7ffc0cfd1b58, env=0x7ffc0cfd1b70) at dl-init.c:120
#4  0x7fd87d8b4f38 in dl_open_worker (a=a@entry=0x7ffc0cfcc990) at 
dl-open.c:575
#5  0x7fd87d8b0754 in _dl_catch_error 
(objname=objname@entry=0x7ffc0cfcc980, 
errstring=errstring@entry=0x7ffc0cfcc988, 
mallocedp=mallocedp@entry=0x7ffc0cfcc97f, 
operate=operate@entry=0x7fd87d8b4b50 , 
args=args@entry=0x7ffc0cfcc990) at dl-error.c:187
#6  0x7fd87d8b46e9 in _dl_open (file=0x561842bac540 
"/usr/local/freeswitch/mod/mod_commands.so", mode=-2147483646, 
caller_dlopen=0x7fd87cd637da , nsid=-2, argc=, argv=, env=0x7ffc0cfd1b70) at dl-open.c:660
#7  0x7fd87c67cee9 in dlopen_doit (a=a@entry=0x7ffc0cfccbc0) at dlopen.c:66
#8  0x7fd87d8b0754 in _dl_catch_error (objname=0x561842b78930, 
errstring=0x561842b78938, mallocedp=0x561842b78928, operate=0x7fd87c67ce90 
, 
args=0x7ffc0cfccbc0) at dl-error.c:187
#9  0x7fd87c67d531 in _dlerror_run (operate=operate@entry=0x7fd87c67ce90 
, args=args@entry=0x7ffc0cfccbc0) at dlerror.c:163
#10 0x7fd87c67cf82 in __dlopen (file=, mode=mode@entry=2) at 
dlopen.c:87

Bug#628583: [Srtp-development] bus error on sparc

[Michael Jerris]

If that fixed it.. then the issue is the missing def for FORCE_64BIT_ALIGN.  
Also of note, that pad shouldn't be there anymore after algorithm was added I 
suspect, as it always serves the same purpose.

On Jul 18, 2013, at 3:10 PM, John Foley fol...@cisco.com wrote:

 You're using the legacy crypto implementation with that configuration.  
 OpenSSL is not in the picture.
 
 Looking at the diffs between master and feature-openssl, there's not much 
 jumping out at me that would have resolved the problem.  There are some 
 changes to the Makefile.  The only other difference that may impact alignment 
 issues is the delta in crypto/include/cipher.h.  Here's the delta:
 
 @@ -163,6 +163,7 @@ typedef err_status_t (*cipher_set_iv_func_t)
 #ifdef FORCE_64BIT_ALIGN
intpad;
  #endif
 +  int algorithm;
  } cipher_t;
  
 Maybe your compiler has laid-out this struct differently due to this new 
 member.  You might try applying this modification to master to see if that 
 resolves the problem.  If not, then I would suspect something in the Makefile 
 deltas.
 
 
 
 
 On 07/18/2013 02:36 PM, Daniel Pocock wrote:
 On 18/07/13 20:17, John Foley wrote:
 
 I should clarify this better.  The legacy crypto is still in the branch.  
 It's pulled out depending on how you've configured the library.  Can you 
 provide the ./configure options you used to build the library?
 
 I just ran 
 
   ./configure  make runtest
 
 
 This is my host
 Linux smetana 2.6.32-5-sparc64-smp #1 SMP Mon Feb 25 02:19:08 UTC 2013 
 sparc64 GNU/Linux
 
 On master, the first test case fails, it is the same error output from 
 Debian bug 628583, but they all run on the branch:
 
 Build done. Please run 'make runtest' to run self tests.
 running libsrtp test applications...
 crypto/test/cipher_driver -v /dev/null
 crypto/test/kernel_driver -v /dev/null
 test/rdbx_driver -v /dev/null
 test/srtp_driver -v /dev/null
 test/roc_driver -v /dev/null
 test/replay_driver -v /dev/null
 test/dtls_srtp_driver /dev/null
 cd test; /home/pocock/ws/srtp/srtp-git/test/rtpw_test.sh /dev/null
 ./rtpw: couldn't open file /usr/share/dict/words
 /home/pocock/ws/srtp/srtp-git/test/rtpw_test.sh: 64: kill: No such process
 
 libsrtp test applications passed.
 make -C crypto runtest
 make[1]: Entering directory `/home/pocock/ws/srtp/srtp-git/crypto'
 test/env # print out information on the build environment
 CPU set to big-endian(WORDS_BIGENDIAN == 1)
 CPU set to RISC(CPU_RISC == 1)
 using native 64-bit type(NO_64_BIT_MATH == 0)
 using stdout for error reporting(ERR_REPORTING_STDOUT == 1)
 using /dev/urandom as a random source(DEV_URANDOM == /dev/urandom)
 running crypto test applications...
 test `test/aes_calc 000102030405060708090a0b0c0d0e0f 
 00112233445566778899aabbccddeeff` = 69c4e0d86a7b0430d8cdb78070b4c55a
 test `test/aes_calc 
 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 
 00112233445566778899aabbccddeeff` = 8ea2b7ca516745bfeafc49904b496089
 test/cipher_driver -v /dev/null
 test/datatypes_driver -v /dev/null
 test/stat_driver /dev/null
 test/sha1_driver -v /dev/null
 test/kernel_driver -v /dev/null
 test/rand_gen -n 256 /dev/null
 crypto test applications passed.
 
 
 
 
 
 
 
 
 On 07/18/2013 02:12 PM, John Foley wrote:
 Which test case was failing?  It's possible the test case is no longer 
 included in the feature-openssl branch.  I pulled out all the legacy 
 crypto and math from libsrtp in that branch.   Have you confirmed the 
 failing test case is still   run under the feature-openssl branch?
 
 
 On 07/18/2013 01:42 PM, Daniel Pocock wrote:
 
 Further observation: the feature-openssl branch from git does not have 
 the bus error, test cases run successfully on SPARC
 
 
 
 
 
 On 18/07/13 19:34, Daniel Pocock wrote:
 
 On 18/07/13 17:26, John Foley wrote:
 
 We've seen BUS errors on some platforms.  I'm not confident the
 following patch was ever pushed back to libsrtp.  There's a chance this
 may resolve the problem on sparc.  Unfortunately I don't have a sparc
 system to try this myself.
 
 
 Thanks for this feedback 
 
 The patch doesn't apply - all but one hunk fails
 
 I tried it against the Debian source package and I also tried applying 
 it against the repository
 
 https://github.com/cisco/libsrtp
 
 Can you tell me the SVN URL where you got this and I can try checking it 
 out and building it?
 
 
 
 
 Modified: branches/proto/libsrtp_30/srtp/include/srtp.h
  ===
  --- branches/proto/libsrtp_30/srtp/include/srtp.h  2013-04-24 
 19:44:23 UTC (rev 1292)
  +++ branches/proto/libsrtp_30/srtp/include/srtp.h  2013-04-29 
 14:17:03 UTC (rev 1293)
  @@ -52,6 +52,11 @@
   
   #ifdef _MSC_VER
   #pragma pack(4)
  +#define PACK
  +#elif defined(__GNUC__)
  +#define PACK __attribute__ ((packed))
  +#else
  +#define PACK
   #endif
   
   #include crypto_kernel.h
  
  Modified: 

Bug#628583: [Srtp-development] bus error on sparc

[Michael Jerris]

If you don't remove that block from the code after that other var was added… it 
will cause this error to come back on that branch now that you've forced the 
64bit align

On Jul 18, 2013, at 5:42 PM, Daniel Pocock dan...@pocock.com.au wrote:

 
 
 On 18/07/13 21:25, Michael Jerris wrote:
 If that fixed it.. then the issue is the missing def for FORCE_64BIT_ALIGN.  
 Also of note, that pad shouldn't be there anymore after algorithm was added 
 I suspect, as it always serves the same purpose.
 
 
 Ok, I've just manually checked that it works on our sparc machine
 https://db.debian.org/machines.cgi?host=smetana
 
 I did this test in the build tree from the Debian source package
 http://anonscm.debian.org/gitweb/?p=collab-maint/srtp.git;a=summary
 
 ./configure CPPFLAGS='-DFORCE_64BIT_ALIGN'  make runtest
 
 
 No more bus error, it proceeds much further, but it still fails with an
 error status:
 
 
 $ make runtest
 Build done. Please run 'make runtest' to run self tests.
 running libsrtp test applications...
 crypto/test/cipher_driver -v /dev/null
 crypto/test/kernel_driver -v /dev/null
 test/rdbx_driver -v /dev/null
 test/srtp_driver -v /dev/null
 test/roc_driver -v /dev/null
 test/replay_driver -v /dev/null
 test/dtls_srtp_driver /dev/null
 cd test; /home/pocock/ws/srtp/srtp/test/rtpw_test.sh /dev/null   
 libsrtp test applications passed.
 make -C crypto runtest
 make[1]: Entering directory `/home/pocock/ws/srtp/srtp/crypto'
 test/env # print out information on the build environment
 CPU set to big-endian (WORDS_BIGENDIAN == 1)
 CPU set to RISC   (CPU_RISC == 1)
 using native 64-bit type  (NO_64_BIT_MATH == 0)
 using stdout for error reporting  (ERR_REPORTING_STDOUT == 1)
 using /dev/urandom as a random source (DEV_URANDOM == /dev/urandom)
 running libcryptomodule test applications...
 test `test/aes_calc 000102030405060708090a0b0c0d0e0f
 00112233445566778899aabbccddeeff` = 69c4e0d86a7b0430d8cdb78070b4c55a
 test `test/aes_calc
 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
 00112233445566778899aabbccddeeff` = 8ea2b7ca516745bfeafc49904b496089
 test/cipher_driver -v /dev/null
 test/datatypes_driver -v /dev/null
 test/stat_driver /dev/null
 make[1]: *** [runtest] Error 1
 make[1]: Leaving directory `/home/pocock/ws/srtp/srtp/crypto'
 make: *** [runtest] Error 2
 
 
 
 although running it again with
 
  make runtest
 
 it finishes successfully the second time.
 
 I've now added FORCE_64BIT_ALIGN to the debian/rules file in our source
 package - should this be used on any other 64 bit platforms?
 
 The Debian package still doesn't build completely though, it appears to
 fail the same way as the manual attempt above.  If I execute make
 runtest immediately after it fails, then it runs the tests again and it
 is successful.
 
 Commenting out test/stat_driver in crypto/Makefile I was able to make it
 run successfully in a single run
 
 Then I cleaned the source tree again but instead of commenting out
 test/stat_driver I just removed the redirect to /dev/null, now I get this:
 
 test/stat_driver
 statistical tests driver
 running stat_tests on all-null buffer, expecting failure
 monobit 11
 poker   11
 runs11
 running stat_tests on rand(), expecting success
 monobit 0
 poker   0
 runs0
 running stat_tests on AES-128-ICM, expecting success
 error (code 6)


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org