evince crashed with SIGSEGV in spectre_gs_send_page()

looks like a libspectre issue, re assigning.

StacktraceTop:spectre_gs_send_page (gs=0x0, doc=0x1603660,
spectre_exporter_pdf_do_page (
ev_job_print_run (job=0x19d7710) at ev-jobs.c:1298
ev_job_thread_proxy (data=<value optimized out>)
?? () from /usr/lib/libglib-2.0.so.0

Hi there.

I've been bitten by this one for almost a year and I just took some time to discover what the hell was happening here.

After bisecting here the git tree from upstream, I noticed an error: the commit 52fa52f93943a6154cf2ac9b473d6b4948d75a15 changes a cast from an unsigned long long int to a uintptr_t. This may have worked on some architectures, but it surely doesn't work on some 32-bit arches. In particular, on PowerPC, this leads to very bad results:

#include <stdio.h>

int main(void)
{
 printf("%llu\n", (unsigned long int) 42);
 printf("%llu\n", (unsigned long long int) 42);
 return 0;
}

produces here:

183609205424
42

The problem with the code is in libspectre/spectre-device.c, around line 240. Reverting the commit 52fa52f93943a6154cf2ac9b473d6b4948d75a15 fixes this here and makes everything work fine. I can confirm that the file that the original poster posted here works fine now.

BTW, just for the record, here are the sizes, in bytes, of the integral and pointer types in the 32 and 64-bit archictectures under Linux:

| | 32 bits arch | 64 bits arch |
| int | 4 | 4 |
| long | 4 | 8 |
| long long | 8 | 8 |
| pointer | 4 | 8 |
| short | 2 | 2 |

Sorry if this shows up messed up, but seeing with a fixed-width font makes things nicer---otherwise, see http://wiki.debian.org/ArchitectureSpecificsMemo.

In summary, we need the field to always be 8-bytes long and simply using a (unsigned) long is enough for, say, amd64, but not for powerpc. We really want a type that is 8-bytes wide in both arches and this should be a long long.

Otherwise, the instruction to use a format string of llu (or llx, for that matter) on a printf-like function makes the function read information that is not part of the integral argument being passed.

Regards,

Hi.

Here is the reversal of the commit that I mentioned earlier. Please, do apply it, as it is very important to have this fixed, especially for a long term release.

Regards.

So, would it be possible to have this segfault fixed in time for the release?

It is a very important fix *at* *least* for those running big endian machines. A reply is welcome, even if only to say "no, it won't be accepted".

Thanks.

Just for the record, I marked this bug as nominated to both karmic and lucid since this is a regression and I can attest that, at least, those two releases contain this bug.

Regards.

So, would it be possible to have this segfault fixed in time for the release?

It is a very important fix at least for those running big endian machines (which includes powerpc and sparc). A different version of the fix (but equally good) is already commited in upstream's repository for some time, and also verified.

http://cgit.freedesktop.org/libspectre/commit/?id=35aa9dfac2631de24a40d95d1469acb52f379249

If you want the least disruptive change, one that can be applied in a wide range of releases, then the patch that I attached to this bug should be the first choice.

Anyway, a reply is welcome, even if only to say "no, it won't be accepted", so that I don't waste my time anymore. The technical background of *why* the bug happens and how to fix it is at

https://bugs.edge.launchpad.net/ubuntu/+source/libspectre/+bug/298139/comments/5

Thanks, Rogério Brito.

Thanks! I'll backport the fix, thanks for digging it out.

On Wed, Apr 14, 2010 at 12:12, Martin Pitt <email address hidden> wrote:
> Thanks! I'll backport the fix, thanks for digging it out.

Thanks, Martin! You've just made my day! You rock.

Thanks again, Rogério Brito.

--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

Hm, with that upstream patch applied I still get the crash with that example document ecrs.ps.

I also still get the crash with Roderigo's patch.. what the heck is wrong here?

Hi, Martin.

On Thu, Apr 15, 2010 at 04:49, Martin Pitt <email address hidden> wrote:
> Hm, with that upstream patch applied I still get the crash with that
> example document ecrs.ps.

This is strange. What platform are you testing this with? Any
big-endian? I can try to experiment with what you have.

Regards,

--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

Rogério Theodoro de Brito [2010-04-15 9:01 -0000]:
> This is strange. What platform are you testing this with? Any
> big-endian? I can try to experiment with what you have.

amd64, just like you..

Linux tick 2.6.32-20-generic #30-Ubuntu SMP Mon Apr 12 15:20:57 UTC 2010 x86_64 GNU/Linux

(amd64 is little endian)

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Hi, Martin.

On Thu, Apr 15, 2010 at 06:44, Martin Pitt <email address hidden> wrote:
> Rogério Theodoro de Brito [2010-04-15  9:01 -0000]:
>> This is strange. What platform are you testing this with? Any
>> big-endian? I can try to experiment with what you have.
>
> amd64, just like you..

No, I observed the problem with a big-endian machine (a powerpc).

Would you like any extra details? Perhaps we have more than one
problem, then. Did you happen to use gdb to find out where the problem
comes from?

I am, right now, using a i386, but I have here in this room both an
amd64 and a powerpc. With the i386 and the powerpc, I don't see any
problems with the patch (any of them) applied.

If you suspect that the problem is indeed at the same place of the
problem of the cast, can you see what value the variable contain?

Regards, Rogério Brito.

--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

> No, I observed the problem with a big-endian machine (a powerpc).

Ah, but this crash was reported on amd64.

(Will followup on the rest later, right now there's too much release related work, sorry)

Hi, Martin.

On Mon, Apr 19, 2010 at 10:27, Martin Pitt <email address hidden> wrote:
>> No, I observed the problem with a big-endian machine (a powerpc).
>
> Ah, but this crash was reported on amd64.

Ouch. You are right. The file is perfectly viewable in a PowerPC,
after my patch.

> (Will followup on the rest later, right now there's too much release
> related work, sorry)

OK, just take your time. Whenever you have some minutes to spare, we
can team up and debug it

Regards, Rogério Brito.

--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

On current lucid amd64, I get

#0 spectre_gs_process (gs=0x0, filename=0x7f75d400a720 "/tmp/ecrs.ps", x=0, y=0, begin=406, end=319212)
    at spectre-gs.c:91
#1 0x00007f75d9ae71e1 in spectre_gs_send_page (gs=0x0, doc=0x7f75d400be80, page_index=1, x=0, y=0)
    at spectre-gs.c:241
#2 0x00007f75d9ae8717 in spectre_exporter_pdf_do_page (exporter=0x7f75e9499460, page_index=0)
    at spectre-exporter-pdf.c:71

which is exactly the same as the original stack trace reported here. Looking at the code, this crashes in

        void *ghostscript_instance = gs->ghostscript_instance;

which is quite obvious since gs is NULL. Walking back through the stack trace and looking through the code, this gs instance is supposed to be set in spectre_exporter_pdf_begin() with a spectre_gs_new() call.

It looks like this amd64 crash is a logic error and unrelated to the libspectre crash that you see (which should be fixed in any case, but perhaps in a separate bug report)?

Hi, Martin.

Just for the record, upstream has released 0.2.5 and it includes the patch. Please, see:

http://cgit.freedesktop.org/libspectre/commit/?id=ee8c5a19138f33dd4c40da4e3def16eba48eccc1

Also, the package is already in Debian unstable:

http://packages.qa.debian.org/libs/libspectre/news/20100421T000301Z.html

I think that if you want, we can join and debug this thing so that we release lucid working on ppc, amd64 and x86 (and this covers a wide range of platform possibilities---big endian, 64 bit, little endian etc).

Regards, Rogério Brito.

Rogério Theodoro de Brito [2010-04-21 10:36 -0000]:
> Hi, Martin.
>
> Just for the record, upstream has released 0.2.5 and it includes the
> patch.

Ah, and it seems the next one might very well be a fix for the
original crash here (that I see as well) on amd64:

http://cgit.freedesktop.org/libspectre/commit/?id=ce55aa1110f3b933943a92ecd0a948d017cdb492

> I think that if you want, we can join and debug this thing so that we
> release lucid working on ppc, amd64 and x86 (and this covers a wide
> range of platform possibilities---big endian, 64 bit, little endian
> etc).

This will need to become a stable release update, though (which is
fine).

On Apr 21 2010, Martin Pitt wrote:
> Ah, and it seems the next one might very well be a fix for the
> original crash here (that I see as well) on amd64:
>
> http://cgit.freedesktop.org/libspectre/commit/?id=ce55aa1110f3b933943a92ecd0a948d017cdb492

Did you test it? I am not at my amd64 right now, so even if I had a
cross-compilation environment, it would not be like the real thing.

> This will need to become a stable release update, though (which is
> fine).

How should this be done? Which steps should I follow?

Thanks for being so nice and quick with your replies,

--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Hi, Martin.

Just another feedback, for some reason, using a very, very up-to-date lucid, with stock libspectre (0.2.3-2) on an amd64, I can't reproduce the bug with the article attached to this bug report.

Something must be fishy here...

Regards, Rogério Brito.

I can still reproduce it. With the two patches applied (http://cgit.freedesktop.org/libspectre/commit/?id=8a720825f6ee77d6945833c59609f6a9141dad19 as well, as a prerequisite) the crash is gone, but the resulting PDF file is still empty. Thus this doesn't seem to be a substantial improvement to me, since in the end the gs instance was NULL because of a rendering error in gs (i. e. a gs bug or the postscript was genuinely broken).

Patch accepted upstream and should be synced for lucid+1.

Is this bug still reproduceable with libspectre 0.2.6?

I can't reproduce this bug since the original test file is now unavailable. However, since the patch has been incorporated in libspectre 0.2.6, I will mark this bug as fixed.

Hi! I can confirm the fix: i have a ps, which was affected by this bug.
For sure attached the file and the screenshot of the bug.

Thx.

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".