Pontus Lidman wrote:
> Consider the following situation: breakpoint at app_procs.c:263 which
> is the line:
>
> ef->export(diagram->data, export_file_name, in_file_name, ef->user_data);
>
> Let's examine the arguments:
>
> (gdb) print diagram->data
> $4 = (DiagramData *) 0x8186a60
> (gdb) print export_file_name
> $5 = 0x80d6230 "3D-engine.png"
> (gdb) print in_file_name
> $6 = 0xbffffc6f "3D-engine.dia"
> (gdb) print ef->user_data
> $7 = (void *) 0x0
>
> Then step to the next line
>
> (gdb) step
> export_png (data=0xbffffc61, filename=0xbffffc6f "3D-engine.dia",
> diafilename=0x0, user_data=0xbffffc7d) at export_png.c:48
> 48 Rectangle *ext = &data->extents;
>
> Now look at the arguments, they are not in the proper position.
> filename is "3D-engine.dia" which was the value of 3rd argument
> in_file_name, and look at the first argument:
>
> (gdb) print (char*) data
> $8 = 0xbffffc61 "3D-engine.png"
I don't know if it's relevant, but I noticed something else here as
well.
The address sent does not seem to be the same as received in the 'data'
parameter, even if we consider the "one position shifting" of the
arguments.
Before the call you report it to be 0x80d6230, but afterwards it becomes
0xbffffc61. Yet, I cannot see any clue of, or reason for, any string
duplication here... Have you (accidentally?) done anything with the
prototyping of DiaExportFunc, maybe?
What were the values of 'ef', 'ef->export', and '&export_png' -- are
they consistent?
> So has anybody else had problems with the PNG export? Or is this a
> compiler bug?
I've sometimes experienced similar "strange" behavior with various C/C++
compilers as well, suspecting the compiler to be buggy... Unfortunately,
mostly it was my own fault <g>.
However, sometimes it helps to do a full recompile...
Otherwise, have you studied the assembly code? (This like the
prolog-code springs to mind.)
Regards,
-+-Ben-+-
