On Wed, Feb 13, 2013 at 04:14:06PM +0000, Martin Crossley wrote:
> On Wed, Feb 13, 2013 at 03:47:25PM +0100, Matthias Kilian wrote:
> > There's some more debugging output, but the above two bits matter.
> > They produce the following output:
> >
> > DEBUG2: (2) pdev = 0x80a26034, pdev->icc_struct = 0x8450b098
> > DEBUG2: gsicc_set_device_profile: (0) pdev = 0x80a26034,
> > pdev->icc_struct=0x0
>
> I see what you mean. In some ways it is lucky that this (whatever it is)
> manifests itself as something so clear as a segfault, otherwise it would
> have never shown up.
>
> So if you run under gdb with that debug code included, does the icc_struct
> member remain intact?
I thought I'd seen it work *iff* running in gdb with a breakpoint
set at gsicc_set_device_profile, but that was the other day, late
in the evening, so I was wrong.
But I noticed that *pdev in gsicc_set_device_profile() looked
different from *pdev in cups_set_color_info (the calling function).
In both functions, gdev is a gx_device pointer (and gx_device is
just a typedef of a struct). So I added debugging output to display
the offset of icc_struct and -- after finding that the data displayed
in gdb differed starting at comp_mask (an array of gx_color_index)
-- the size of gx_color_index. Just for joy and fun.
> Ait feels like getting closer... many thanks again for your work on this.
Indeed:
gdevcups.c: offsetof(gx_device, icc_struct) = 500
gdevcups.c: sizeof(gx_color_index) = 4
gsicc_manage.c: offsetof(gx_device, icc_struct) = 640
gsicc_manage.c: sizeof(gx_color_index) = 8
This looks like some #include and/or #define fuckup (ghostscript
is heavily abusing the preprocessor in very bad ways, to simulate
something like inheritance and also to make it unmaintainable and
unreadable).
Ciao,
Kili
