Bug#484454: [: Re: Bug#471348 closed by Lior Kaplan <kaplan@debian.org> (openoffice.org: Segmentation fault trying to open a .sdc)]

[Paolo <oopla@users.sf.net>]

excerpt from last post to #471348 ...

> ----- Forwarded message from  -----

> Anyway, I was going to reply to #471348#39, as I got the chance to test
> latest 2.4.0: I couldn't make it segv on those files, yet I see a funny
> behaviour, on a few .sdc: it hangs indefinitely taking away the CPU, on
> a pc with AMD Duron 1.3G + 512MB + k2.6.22.19 + Etch
>   VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
>   204m  78m  57m R 96.8 15.6   4:55.97 soffice.bin 
> while it works on AMD Athlon XP 2800+ + 1G + k2.6.22.19 + Etch.
> And, in this case, OOo2 2.4.0 from upstream hangs as well.

> Again, not a glitch with OOo1.1.5.

> Going to debianize 2.4.1 and see if they got it right eventually.
...

ok, doesn't segv but hangs, so seems we're in #484454 domain.

Debianized (though not really needed) 2.4.1 from upstream, but same result:
works on 2nd pc with Athlon etc, hangs on 1st pc with Duron etc.
At this point I guess 2.4.1-bpo* won't make much difference, unless there are
clues that Debian's patches may have addressed troubles in libs mentioned 
here below.

Digging further in, seems the culprit is PPD parsing function: thread
hangs after loading the PPD for the default printer as set in the .sdc:

[pid 21529] open("/mnt/opt/openoffice.org2.4/program/../share/psprint/driver/HP4SI6_1.PS", O_RDONLY) = 29

which is the HP4SI6_1.PS included in upstream .rpm (which is the same as in 
the OOo1.1.5 pkg), 

$ strings documenti/Moduli_CAM.sdc | grep -i kyo
Kyo1010 600dpi (contab, emul ljet4)_
$ grep Kyo1010 .openoffice.org2/user/psprint/psprint.conf
[Kyo1010 600dpi (contab, emul ljet4)_]
Printer=HP4SI6_1.PS/Kyo1010 600dpi (contab, emul ljet4)_

and gdb backtrace shows looping around here:

(gdb) bt
#0  0xb67e224a in psp::PPDKey::getValue ()
   from /mnt/opt/openoffice.org2.4/program/libpsp680li.so
#1  0xb67e3d4b in psp::PPDContext::resetValue ()
   from /mnt/opt/openoffice.org2.4/program/libpsp680li.so
#2  0xb67e3c3e in psp::PPDContext::setValue ()
   from /mnt/opt/openoffice.org2.4/program/libpsp680li.so
#3  0xb50e8c45 in X11SalInstance::CreatePrinter ()
   from /mnt/opt/openoffice.org2.4/program/libvclplug_gen680li.so
#4  0xb50ea107 in X11SalInstance::GetPrinterQueueInfo ()
   from /mnt/opt/openoffice.org2.4/program/libvclplug_gen680li.so
#5  0xb7cfdac0 in Printer::SetJobSetup ()
   from /mnt/opt/openoffice.org2.4/program/libvcl680li.so
#6  0xafb73cd6 in binfilter::SfxPrinter::SfxPrinter ()
   from /mnt/opt/openoffice.org2.4/program/libbf_svx680li.so
#7  0xafb73d5e in binfilter::SfxPrinter::Create ()
   from /mnt/opt/openoffice.org2.4/program/libbf_svx680li.so
#8  0xaf07489d in component_getFactory ()
   from /mnt/opt/openoffice.org2.4/program/libbf_sc680li.so
#9  0xaef8f8cc in DeInitScDll ()
   from /mnt/opt/openoffice.org2.4/program/libbf_sc680li.so
#10 0xaef91caa in CreateScDocShellDll ()
   from /mnt/opt/openoffice.org2.4/program/libbf_sc680li.so
#11 0xafb5ed5f in binfilter::SfxObjectShell::LoadOwnFormat ()

I've removed all printers from config, leaving only the 'generic' one and 
the one specified in the .sdc, and it hangs (loop); if I leave all the 
others but remove just the one named in the .sdc, all goes well.
Likewise, changing HP4SI6_1 -> HP4PLUS6 in user/psprint/psprint.conf

Thus, seems that either the PPD parser is broken or it breaks while 
working with the binfilter.


-- 
paolo