Hi list,
just to let you know that this did the trick : install glib on my development
machine without the AVX instructions (-mno-avx), and build fluidsynth/fluidXtra
against it.
Thank you for your help
Antoine
Le 23 août 2013 à 18:10, Element Green a écrit :
> Sounds like you're onto somethi
Sounds like you're onto something there. I was not aware of VEX-prefixed
AVX instructions. I thought it seemed a little fishy that the LDS
instruction would be used in that disassembly dump and also that it
appeared that the actual instruction was 8 bytes long from your successful
single stepping
well,
I installed glib as --universal, meaning that it contains both 32 bits and 64
bits binaries. And actually, I removed the 64 bit binary (using the lipo
function), because Director is a 32 bits application and all Xtras (plugins)
are also. So we are really running in 32 bit here. Even on Mac
Not sure what happened with the address typo, since I thought I copy and
pasted it too. Glad you caught it.
>From what I can see, that instruction is indeed an LDS instruction, which
from what I read is invalid when in 64 bit mode. It sounds like Mac OSX
can be run in either 32 bit or 64 bit mod
Hum sorry,
this seemed fishy so I did :
(gdb) x/8bx thread_memory_from_self+187
0x34894bc :0xc50xfb0x100x83
0xad0x410x0a0x00
which looks more like it. I think that you did a typo when typing 0x039894bc
(which I then copied without checking..) instead of 0x34894
Le 21 août 2013 à 16:41, Element Green a écrit :
> You should be able to do that like:
> x/8bx 0x039894bc
>
(gdb) x/8bx 0x039894bc
0x39894bc: 0xe10xee0xee0xee0xe10xee0xee0xee
>
> Do you know any details about the differences in the CPUs? Maybe th
On Wed, 21 Aug 2013, Element Green wrote:
Time to look at the actual machine code,
Or maybe get a new gdb and hope that it can put an opcode to the
instruction.
Although as far as I know most CPUs should be 64 bit capable these days.
I dunno. It looks like x86 Macs can pack anything fro
On Wed, Aug 21, 2013 at 7:11 AM, a...@gratin.org wrote:
> Well,
> remember that the core dump was from a Mac system on which glib crashes.
> The same app does not crash on most systems, including mine.
> I just ran the app on gdb on my system, and disassembled the same function
> (before running
Just as a precision. On my machine, I disassembled the function _after_
starting the program. Not before. For what it is worth. In case it makes a
difference in the thinking.
++ as :: Antoine Schmitt :: iPhone
Le 21 août 2013 à 15:11, "a...@gratin.org" a écrit :
> I just ran the app on gdb o
Well,
remember that the core dump was from a Mac system on which glib crashes. The
same app does not crash on most systems, including mine.
I just ran the app on gdb on my system, and disassembled the same function
(before running the program). This showed to the same instructions as in the
core
On 08/21/2013 01:37 PM, a...@gratin.org wrote:
> Hi,
>
> so I moved along with this problem, analyzing the core dump.
> Unfortunately, I did not have the symbols of glib (it seems that 'brew
> install --test glib' did not build a debug version of glib despite what
> the doc says).
> But I could di
Hi,
so I moved along with this problem, analyzing the core dump.
Unfortunately, I did not have the symbols of glib (it seems that 'brew install
--test glib' did not build a debug version of glib despite what the doc says).
But I could disassemble the faulty function :
Dump of assembler code for
Sorry, this is a typo. I meant 2.36.3.
Thank you for all the advices. I will seek to have a core dump and try to find
the fault instruction. Will keep you updated.
Cheers !
Le 20 août 2013 à 01:26, Element Green a écrit :
> I built it against glib 2.26.3, using homebrew, by doing a "brew in
Good points, I forgot that it was an illegal instruction exception when I
wrote that. Getting a core dump is probably the best route to getting this
information.
A quick search reveals that the following command can be run from an OSX
Terminal prior to executing the application (which should also
On Mon, 19 Aug 2013, Element Green wrote:
I've often found that the glib memory slice subsystem can be sensitive
to memory corruption. It could be that there is some other unrelated
memory corruption going on which is causing this.
In that case I'd expect a segfault before anything could int
On Mon, Aug 19, 2013 at 12:04 PM, a...@gratin.org wrote:
> Hello,
>
> Le 16 août 2013 à 18:58, Element Green a
> écrit :
>
> >
> > I had a look at the thread_memory_from_self() function in the glib
> > source code and I don't see anything that would suggest usage of SSE
> > instructions (its a m
I haven't built FluidSynth in a while and just saw those warnings that you
mention.
Looking over the changes with the glib thread API, I see that mutexes are
now generally statically allocated (they could be either statically or
dynamically allocated in previous versions), so the deprecation of
g_
Hello David,
On Mon, Aug 19, 2013 at 1:53 PM, David Henningsson wrote:
> On 08/19/2013 05:55 PM, a...@gratin.org wrote:
> > Hello,
> >
> > trying to build a debug version of glib, and will do some tests on the
> > failing target machines.
> >
> > In the meantime, I wanted to note that when I com
On 08/19/2013 05:55 PM, a...@gratin.org wrote:
> Hello,
>
> trying to build a debug version of glib, and will do some tests on the
> failing target machines.
>
> In the meantime, I wanted to note that when I compile fluidsynth against
> the latest glib (v2.36.3), I get a lot a deprecation warning
Hello,
Le 16 août 2013 à 18:58, Element Green a écrit :
>
> I had a look at the thread_memory_from_self() function in the glib
> source code and I don't see anything that would suggest usage of SSE
> instructions (its a memory allocation function). There is a lot of
> use of the thread system
Hello,
trying to build a debug version of glib, and will do some tests on the failing
target machines.
In the meantime, I wanted to note that when I compile fluidsynth against the
latest glib (v2.36.3), I get a lot a deprecation warnings related to mutex and
threads :
/Users/antoine/Documents
Probably my fault for the multiple email post (got stuck in the admin
interface trap due to its size and I approved it without realizing
that it had made it to the list already somehow).
Anyways..
I had a look at the thread_memory_from_self() function in the glib
source code and I don't see anyth
Hi list,
I have a difficult bug.
I'm building a Adobe Director Xtra, which is a kind of plugin, i.e. a
dynamically loaded library, incorporating fluidsynth.
This is on Mac OSX.
I build this Xtra on my MacOSX 10.8.4 system (Xcode 4.3). Fluidsynth is build
as a static library and is statically link
On Fri, 16 Aug 2013, a...@gratin.org wrote:
I have a difficult bug.
Not really. This kind of thing crops up pretty regularly when trying to
produce portable binaries.
We have a suspicion on the SSE4.2 instruction set, as it seems that this
instruction set is not present on the machines on
Hi list,
I have a difficult bug.
I'm building a Adobe Director Xtra, which is a kind of plugin, i.e. a
dynamically loaded library, incorporating fluidsynth.
This is on Mac OSX.
I build this Xtra on my MacOSX 10.8.4 system (Xcode 4.3). Fluidsynth is build
as a static library and is statically link
25 matches
Mail list logo
