Bug#892272:

2018-03-07 Thread Michael Jerris
confirmed steps to reproduce the issue in the simplest way: # ulimit -s 240 && openmpt123 Segmentation fault

Bug#892272:

2018-03-07 Thread 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

Bug#892272:

2018-03-07 Thread Michael Jerris
Confirmed its the same linking to JUST libopenmpt, without libavformat

Bug#892272: libavformat/libopenmpt failure on dlopen

2018-03-07 Thread 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

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

2013-07-18 Thread 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

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

2013-07-18 Thread 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