Bug 687730 - The garbage collector is broken on linux/ppc
Summary: The garbage collector is broken on linux/ppc
Status: RESOLVED DUPLICATE of bug 687643
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: 7.07
Hardware: Macintosh Linux
: P2 major
Assignee: Jack Moffitt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-05 14:36 UTC by Luca Barbato
Modified: 2007-12-13 12:55 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments
obj/arch.h (1.40 KB, text/plain)
2004-12-09 14:59 UTC, Luca Barbato
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luca Barbato 2004-10-05 14:36:28 UTC
I can reproduce the problem on:
ANY ghostscript esp from the 7.07.1 up to the yesterday cvs
gnu ghostscript 8.15
afpl ghostscript 8.15

the problem is always the same, segfault on load:

I run gdb ./bin/gs

here the traces

ESP GS

Program received signal SIGSEGV, Segmentation fault.
restore_finalize (mem=0x108e8450) at ./src/isave.c:810
810                 struct_proc_finalize((*finalize)) =
(gdb) print *mem
$1 = {stable_memory = 0x108e8750, procs = {
    alloc_bytes_immovable = 0x101de684 <i_alloc_bytes_immovable>,
    resize_object = 0x101dd294 <i_resize_object>,
    free_object = 0x101f3c90 <gs_ignore_free_object>,
    stable = 0x101dd5e4 <i_stable>, status = 0x101dd5ec <i_status>,
    free_all = 0x101deb08 <i_free_all>,
    consolidate_free = 0x101deeec <i_consolidate_free>,
    alloc_bytes = 0x101de560 <i_alloc_bytes>,
    alloc_struct = 0x101de440 <i_alloc_struct>,
    alloc_struct_immovable = 0x101de428 <i_alloc_struct_immovable>,
    alloc_byte_array = 0x101de410 <i_alloc_byte_array>,
    alloc_byte_array_immovable = 0x101de3f8 <i_alloc_byte_array_immovable>,
    alloc_struct_array = 0x101de3e4 <i_alloc_struct_array>,
    alloc_struct_array_immovable = 0x101de3d0 <i_alloc_struct_array_immovable>,
    object_size = 0x101dcde4 <i_object_size>,
    object_type = 0x101dcdec <i_object_type>,
    alloc_string = 0x101ddf6c <i_alloc_string>,
    alloc_string_immovable = 0x101ddf08 <i_alloc_string_immovable>,
    resize_string = 0x101dd474 <i_resize_string>,
    free_string = 0x101f3c94 <gs_ignore_free_string>,
    register_root = 0x101dda88 <i_register_root>,
    unregister_root = 0x101ddb1c <i_unregister_root>,
    enable_free = 0x101dd6ec <i_enable_free>}, parent = 0x108e8148,
---Type <return> to continue, or q <return> to quit---
  chunk_size = 20000, large_size = 4993, space = 12, gc_status = {
    vm_threshold = 60000, max_vm = 2147483647, psignal = 0x0, signal_value = 0,
    enabled = 0, requested = 0}, is_controlled = 0, limit = 8000000,
  cfirst = 0x108e83a0, clast = 0x1092b8f0, cc = {chead = 0x108f8aa0,
    cbase = 0x108f8ac0 "", int_freed_top = 0x108f8ac0 "", cbot = 0x108f9e88 "",
    rcur = 0x108f9b50, rtop = 0x108f9b98 "", ctop = 0x108fcc40 "",
    climit = 0x108fcc40 "", cend = 0x108fd8c0 "", cprev = 0x108e83a0,
    cnext = 0x1090df80, outer = 0x0, inner_count = 0, has_refs = 1,
    sfree1 = 0x108fd470, sfree = 0, odest = 0x0, smark = 0x108fcc40 "",
    smark_size = 2096, sbase = 0x108f8ac0 "", sreloc = 0x108fd470, sdest = 0x0,
    rescan_bot = 0x0, rescan_top = 0x0}, pcc = 0x108f8a20, cfreed = {memory = 0x0,
    cp = 0x0}, allocated = 141712, inherited = 0, gc_allocated = 0, lost = {
    objects = 0, refs = 0, strings = 0}, save_level = 0, new_mask = 0,
  test_mask = 4294967295, streams = 0x0, names_array = 0x0, roots = 0x0,
  num_contexts = 1, changes = 0x0, saved = 0x0, total_scanned = 0,
  reloc_saved = 0x0, previous_status = {allocated = 0, used = 0},
  largest_free_size = 0, freelists = {0x0 <repeats 52 times>}}


GNU GS

Program received signal SIGSEGV, Segmentation fault.
gc_objects_clear_marks (cp=0x102a0a50) at ./src/igc.c:582
582             struct_proc_clear_marks((*proc)) =
(gdb) print *cp->chead
Cannot access memory at address 0xe000000
(gdb) print *cp
$8 = {chead = 0xe000000, cbase = 0x0,
  int_freed_top = 0xf8005a9 <Address 0xf8005a9 out of bounds>,
  cbot = 0x100a7a9c "<\200\020\n8\204yhK&#65533;&#65533;,\224!&#65533;p|\b\002&#65533;\223&#65533;", rcur = 0xe000000,
  rtop = 0x0, ctop = 0xe000000 <Address 0xe000000 out of bounds>, climit = 0x0,
  cend = 0xf800582 <Address 0xf800582 out of bounds>, cprev = 0x100a630c,
  cnext = 0xe000000, outer = 0x0, inner_count = 234881024, has_refs = 0,
  sfree1 = 0xe000000, sfree = 0,
  odest = 0xe000000 <Address 0xe000000 out of bounds>, smark = 0x0,
  smark_size = 260048289, sbase = 0x100a6564 "|\b\002&#65533;\224!&#65533;&#65533;\223&#65533;",
  sreloc = 0xe000000, sdest = 0x0,
  rescan_bot = 0xe000000 <Address 0xe000000 out of bounds>, rescan_top = 0x0}



System summary
(default-linux/ppc/2004.3, gcc-3.4.1, glibc-2.3.4.20040808-r0, 2.6.8-gentoo-r4 ppc)
=================================================================
System uname: 2.6.8-gentoo-r4 ppc 7455, altivec supported
Gentoo Base System version 1.5.3
distcc 2.17 powerpc-unknown-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
ccache version 2.3 [enabled]
Autoconf: sys-devel/autoconf-2.59-r4
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.15.90.0.3-r3
Headers:  sys-kernel/linux26-headers-2.6.8.1
Libtools: sys-devel/libtool-1.5.2-r5
Comment 1 Alex Cherepanov 2004-10-05 15:14:12 UTC
This doesn't happen on Darwin system provided by SourceForge
$ uname -a
Darwin ppc-osx2.cf.sourceforge.net 6.8 Darwin Kernel Version 6.8: Wed Sep 10
15:20:55 PDT 2003; root:xnu/xnu-344.49.obj~
2/RELEASE_PPC  Power Macintosh powerpc
$ gcc --version
gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1493)

How can I get hold on Linux on PPC?
Comment 2 Luca Barbato 2004-10-05 15:29:58 UTC
I can get you an account on a local box here (the only problem is that I'm on a
dialup most time)
Comment 3 Ralph Giles 2004-10-06 08:40:11 UTC
Can you post the file you're running that shows this problem? I do regular
development on linux ppc and have never noticed such a problem.

Of course, we distribute none of the versions you mention. Do you mean GPL
Ghostscript 8.15?
Comment 4 Luca Barbato 2004-10-06 08:57:00 UTC
That is the behaviour that applies when no arguments are given (with arguments
given the result is almost the same).

esp sources are the vanilla ones took from sf, the gentoo patched ones and the
cvs source as was 2 days ago.

gnu sources are the ones from the ghostscript-8.15.tar.bz2 tarball.

afpl sources are again the ones from the official tarball.

The problem appear to happen on mandrake too, leading to the very same trace.
Comment 5 Alex Cherepanov 2004-10-06 15:35:57 UTC
The patch for the bug 687643 helps here too.
Thanks to Mr. Barbato for verifying this.


*** This bug has been marked as a duplicate of 687643 ***
Comment 6 Ralph Giles 2004-12-06 11:09:55 UTC
Luca,

We were just reviewing this in the context of Bug 687643, and it seems odd that
this issue would be related. Just to check whether gcc 3.4 has done something
odd with the ppc alignment, can you atttach the obj/arch.h you get from this bug?
Comment 7 Luca Barbato 2004-12-09 14:59:02 UTC
Created attachment 1087 [details]
obj/arch.h

I'm sorry for the delay of the reply but I got some connectivity (now hopefully
fixed) and some hardware (yet to repair, but a second battery is helping enough
to let me check email and hopefully provide the information you need).

I hope it helps.
Comment 8 Alex Cherepanov 2004-12-09 17:39:06 UTC
This bug is indeed realted to the bug 687643.

ARCH_ALIGN_PTR_MOD == 4  ==> sizeof(ref) == 8
ARCH_ALIGN_STRUCT_MOD == 16 

When sizeof(ref) < ARCH_ALIGN_STRUCT_MOD Ghostscript requires the
patch submitted on 2004-09-14 for the bug 687643.
Comment 9 Ralph Giles 2004-12-09 17:59:11 UTC
Ok, thanks; as Alex says, arch.h is complatible with the diagnosis of 687643.
Closing this one (again) as a duplicate. I believe Raph has a preferred fix
which will be committed after the 8.50 release freeze.

*** This bug has been marked as a duplicate of 687643 ***