Bug#493624: zoem: segmentation fault during translation to html
On Thursday 21 August 2008 02:11:01 Stijn van Dongen wrote:
I've had a quick look (as I have a powerPC minimac), but everything works
here. Perhaps that is to be expected with different OS, libs etc.
It could be a bug in the hashing code. This can be tested to an unknown
extent as follows:
zoem -i mcxconvert.azm -d html -hf elf
zoem -i mcxconvert.azm -d html -hf djb
(these equip zoem with different hash functions). Then, ideally, someone
should run a zoem compiled with -g (debugging info added; does Debian
provide such a thing automatically?), re-establish the bug, and then do
1) gdb zoem
2) issue 'run -i mcxconvert -d html'
3) issue 'bt'
Testing the program with different hashing functions did not result in any
different behaviour, they both fail with the same error.
I've attached a gdb backtrace to this mail, hopefully this will give you an
idea what might be wrong.
Regards,
Tobias
--
Tobias Quathamer | Time wounds all heels. -- Groucho Marx
Hamburg, Germany |
$ gdb ../zoem-07-333/src/zoem
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as powerpc-linux-gnu...
(gdb) run -i mcxconvert.azm -d html
Starting program: /home/toddy/zoem/zoem-07-333/src/zoem -i mcxconvert.azm -d
html
[zinsert#1] failure opening file mcxconvert.zmt (rerun?)
Program received signal SIGSEGV, Segmentation fault.
0x0fe35488 in strlen () from /lib/libc.so.6
(gdb) bt
#0 0x0fe35488 in strlen () from /lib/libc.so.6
#1 0x0fdfe3f4 in vfprintf () from /lib/libc.so.6
#2 0x0fe23ce8 in vsnprintf () from /lib/libc.so.6
#3 0x10021f9c in mcx_ting_print (dst=0x1005f560, fmt=0x100263d4 \\%s{%s},
args=0x7fe031b8) at ting.c:141
#4 0x100220e0 in mcxTingPrint (dst=value optimized out,
fmt=value optimized out) at ting.c:201
#5 0x1000251c in yamXtag (seg=0x10055fbc, dev=0x1005e0e0, arg=0x1005f510)
at ops-xtag.c:51
#6 0x1000e8f4 in expandXtag2 (seg=0x10055fbc) at ops.c:1050
#7 0x10013984 in yamExpandKey (seg=0x10055fbc, keybits=1) at parse.c:815
#8 0x10013b5c in yamDoKey (seg=0x10055fbc) at parse.c:616
#9 0x10005658 in yamDigest (txtin=0x1005a380, txtout=value optimized out,
baseseg=0x10055fa4) at digest.c:201
#10 0x1000246c in yamXtag (seg=0x10055fa4, dev=0x1005cbf8, arg=0x1005a380)
at ops-xtag.c:37
#11 0x1000e8f4 in expandXtag2 (seg=0x10055fa4) at ops.c:1050
#12 0x10013984 in yamExpandKey (seg=0x10055fa4, keybits=1) at parse.c:815
#13 0x10013b5c in yamDoKey (seg=0x10055fa4) at parse.c:616
#14 0x10005a38 in yamOutput (txtin=value optimized out, sk=0x0, fltidx=1)
at digest.c:97
#15 0x10006ee0 in sourceAscend (fnsearch=value optimized out, modes=40,
chunk_size=1048576) at source.c:313
#16 0x1000634c in yamEntry (sfnentry=value optimized out,
---Type return to continue, or q return to quit---
sfnpath=0x10040048 , sfnbase=0x10040018 mcxconvert,
chunk_size=1048576, sfnout=value optimized out,
sdevice=value optimized out, fltidx=2, trace_flags=0, entry_flags=0,
vars=0x10040148, expr=0x100400f8) at entry.c:228
#17 0x10016608 in main (argc=0, argv=value optimized out) at zoem.c:605
signature.asc
Description: This is a digitally signed message part.
Bug#493624: zoem: segmentation fault during translation to html
On Monday 04 August 2008 10:51:56 Tobias Quathamer wrote: I've attached the output of zoem with --trace and --trace-keys enabled and will forward this to the program author. Maybe he'll have an idea. FYI: Upstream is on vacation until August 20 and will look into this bug afterwards. Regards, Tobias -- Tobias Quathamer | AMAZING BUT TRUE ... Hamburg, Germany | There is so much sand in Northern Africa that if it were | spread out it would completely cover the Sahara Desert. signature.asc Description: This is a digitally signed message part.
Bug#493624: zoem: segmentation fault during translation to html
On Sunday 03 August 2008 18:20:43 Philipp Benner wrote: $ zoem -d html -i mcxconvert.azm -o mcxconvert.html zsh: segmentation fault zoem -d html -i mcxconvert.azm -o mcxconvert.html Hi Philipp, thanks for your bug report. However, I was unable to reproduce that behaviour with the file you've attached. In the .azm source, another file (mcx.zmm) is included, which I downloaded from the mcx source tarball (http://micans.org/mcl/src/mcl-08-157.tar.gz). Did you use that version as well? Could you also run the following command: $ strace zoem -d html -i mcxconvert.azm -o mcxconvert.html and send the output to this bug report? Regards, Tobias -- Tobias Quathamer | We all know Cray supercomputers are great... Hamburg, Germany | they do infinite loops in about 4 hours. signature.asc Description: This is a digitally signed message part.
Bug#493624: zoem: segmentation fault during translation to html
Hi Tobias,
thanks for your bug report. However, I was unable to reproduce that behaviour
with the file you've attached. In the .azm source, another file (mcx.zmm) is
included, which I downloaded from the mcx source tarball
(http://micans.org/mcl/src/mcl-08-157.tar.gz). Did you use that version as
well?
Yes, right.
Could you also run the following command:
$ strace zoem -d html -i mcxconvert.azm -o mcxconvert.html
and send the output to this bug report?
Done.
Could it be an arch specific problem? Since I'm using powerpc.
Cheers,
--
Philipp Benner
execve(/usr/bin/zoem, [zoem, -d, html, -i, mcxconvert.azm, -o,
mcxconvert.html], [/* 29 vars */]) = 0
brk(0) = 0x804a000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x3001f000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x3002
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/home/philipp/usr/lib/tls/ppc7450/altivec/libm.so.6, O_RDONLY) = -1
ENOENT (No such file or directory)
stat64(/home/philipp/usr/lib/tls/ppc7450/altivec, 0x7fdaedd8) = -1 ENOENT (No
such file or directory)
open(/home/philipp/usr/lib/tls/ppc7450/libm.so.6, O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64(/home/philipp/usr/lib/tls/ppc7450, 0x7fdaedd8) = -1 ENOENT (No such
file or directory)
open(/home/philipp/usr/lib/tls/altivec/libm.so.6, O_RDONLY) = -1 ENOENT (No
such file or directory)
stat64(/home/philipp/usr/lib/tls/altivec, 0x7fdaedd8) = -1 ENOENT (No such
file or directory)
open(/home/philipp/usr/lib/tls/libm.so.6, O_RDONLY) = -1 ENOENT (No such file
or directory)
stat64(/home/philipp/usr/lib/tls, 0x7fdaedd8) = -1 ENOENT (No such file or
directory)
open(/home/philipp/usr/lib/ppc7450/altivec/libm.so.6, O_RDONLY) = -1 ENOENT
(No such file or directory)
stat64(/home/philipp/usr/lib/ppc7450/altivec, 0x7fdaedd8) = -1 ENOENT (No
such file or directory)
open(/home/philipp/usr/lib/ppc7450/libm.so.6, O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64(/home/philipp/usr/lib/ppc7450, 0x7fdaedd8) = -1 ENOENT (No such file
or directory)
open(/home/philipp/usr/lib/altivec/libm.so.6, O_RDONLY) = -1 ENOENT (No such
file or directory)
stat64(/home/philipp/usr/lib/altivec, 0x7fdaedd8) = -1 ENOENT (No such file
or directory)
open(/home/philipp/usr/lib/libm.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/home/philipp/usr/lib, {st_mode=S_IFDIR|0755, st_size=952, ...}) = 0
open(tls/ppc7450/altivec/libm.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(tls/ppc7450/libm.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
open(tls/altivec/libm.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
open(tls/libm.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
open(ppc7450/altivec/libm.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(ppc7450/libm.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
open(altivec/libm.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
open(libm.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=131476, ...}) = 0
mmap(NULL, 131476, PROT_READ, MAP_PRIVATE, 6, 0) = 0x30031000
close(6)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/libm.so.6, O_RDONLY)= 6
read(6, \177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\313..., 512) =
512
fstat64(6, {st_mode=S_IFREG|0644, st_size=706940, ...}) = 0
mmap(0x7f33000, 770764, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 6, 0) =
0x7f33000
mprotect(0x7fdc000, 65536, PROT_NONE) = 0
mmap(0x7fec000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 6, 0xa9000) = 0x7fec000
close(6)= 0
open(/home/philipp/usr/lib/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(tls/ppc7450/altivec/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(tls/ppc7450/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
open(tls/altivec/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
open(tls/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
open(ppc7450/altivec/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(ppc7450/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
open(altivec/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
open(libc.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/libc.so.6, O_RDONLY)= 6
read(6, \177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\1\351..., 512) =
512
fstat64(6, {st_mode=S_IFREG|0755, st_size=1458348, ...}) = 0
mmap(0x7dad000, 1528376,
Bug#493624: zoem: segmentation fault during translation to html
On Monday 04 August 2008 09:30:52 Philipp Benner wrote: Could it be an arch specific problem? Since I'm using powerpc. Yes, seems so. I've tested on i386, and I didn't find any problem. However, I've now tested the same on powerpc, and it segfaults there for me as well. So it's obviously a problem on powerpc and maybe other arches. It might be that the endianess is the source of the problem, since powerpc uses big endian, while i386 uses little endian. I've attached the output of zoem with --trace and --trace-keys enabled and will forward this to the program author. Maybe he'll have an idea. Regards, Tobias -- Tobias Quathamer | The sum of the intelligence of the world is constant. Hamburg, Germany | The population is, of course, growing. ## |env#4seg 0 stack 0 nr 1 ## |def#2seg 0 stack 0 nr 2 ## |def#2seg 0 stack 0 nr 3 ## |import#1 seg 0 stack 0 nr 4 ## |dofile#2 seg 1 stack 0 nr 5 ## |set#2seg 0 stack 1 nr 6 ## |if#3 seg 0 stack 1 nr 7 ## |cmp#3seg 0 stack 2 nr 8 # #|__version__ seg 0 stack 3 nr 9 # #|reqver seg 0 stack 3 nr 10 ## |input#1 seg 0 stack 1 nr 11 ## |dofile#2 seg 1 stack 1 nr 12 ## |import#1 seg 0 stack 2 nr 13 ## |dofile#2 seg 1 stack 2 nr 14 ## |import#1 seg 0 stack 3 nr 15 ## |dofile#2 seg 1 stack 3 nr 16 ## |if#3 seg 0 stack 4 nr 17 ## |defined#2seg 0 stack 5 nr 18 ## |def#2seg 1 stack 4 nr 19 ## |import#1 seg 0 stack 4 nr 20 ## |dofile#2 seg 1 stack 4 nr 21 ## |if#3 seg 0 stack 5 nr 22 ## |defined#2seg 0 stack 6 nr 23 ## |def#2seg 1 stack 5 nr 24 ## |def#2seg 0 stack 5 nr 25 ## |formatted#1 seg 0 stack 5 nr 26 ## |def#2seg 1 stack 5 nr 27 ## |def#2seg 1 stack 5 nr 28 ## |def#2seg 1 stack 5 nr 29 ## |def#2seg 1 stack 5 nr 30 ## |def#2seg 1 stack 5 nr 31 ## |def#2seg 0 stack 4 nr 32 ## |def#2seg 0 stack 4 nr 33 ## |def#2seg 0 stack 4 nr 34 ## |def#2seg 0 stack 4 nr 35 ## |def#2seg 0 stack 4 nr 36 ## |formatted#1 seg 0 stack 4 nr 37 ## |def#2seg 1 stack 4 nr 38 ## |formatted#1 seg 0 stack 4 nr 39 ## |register#2 seg 1 stack 4 nr 40 ## |formatted#1 seg 0 stack 4 nr 41 ## |def#2seg 1 stack 4 nr 42 ## |def#2seg 1 stack 4 nr 43 ## |import#1 seg 0 stack 3 nr 44 ## |dofile#2 seg 1 stack 3 nr 45 ## |if#3 seg 0 stack 4 nr 46 ## |defined#2seg 0 stack 5 nr 47 ## |done seg 1 stack 4 nr 48 ## |throw#1 seg 2 stack 4 nr 49 ## |throw#2 seg 3 stack 4 nr 50 ## |def#2seg 0 stack 3 nr 51 ## |$#2 seg 0 stack 3 nr 52 ## |set#3seg 1 stack 3 nr 53 ## |set#3seg 1 stack 3 nr 54 ## |set#2seg 1 stack 3 nr 55 ## |$#2 seg 0 stack 3 nr 56 ## |set#2seg 0 stack 3 nr 57 ## |formatted#1 seg 0 stack 3 nr 58 ## |env#4seg 1 stack 3 nr 59 ## |switch#2 seg 0 stack 3 nr 60 # #|__device__ seg 0 stack 5 nr 61 ## |set#3seg 1 stack 3 nr 62 ## |switch#2 seg 0 stack 3 nr 63 # #|__device__ seg 0 stack 5 nr 64 ## |special#1seg 1 stack 3 nr 65 ## |constant#1 seg 1 stack 3 nr 66 ##
Bug#493624: zoem: segmentation fault during translation to html
Package: zoem
Version: 07-333-3
Severity: important
$ zoem -d html -i mcxconvert.azm -o mcxconvert.html
zsh: segmentation fault zoem -d html -i mcxconvert.azm -o mcxconvert.html
The mcxconvert.azm file is attached to this mail.
Cheers!
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.18
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages zoem depends on:
ii libc6 2.7-10 GNU C Library: Shared libraries
zoem recommends no packages.
Versions of packages zoem suggests:
pn zoem-doc none (no description available)
-- no debconf information
--
Philipp Benner
\def{man::synstyle}{long}
\def{man::defstyle}{long}
\import{mcx.zmm}
\set{man::name}{mcx convert}
\set{man::html-title}{The mcx convert manual}
\set{man::author}{Stijn van Dongen}
\set{man::section}{1}
\man::preamble
\${html}{\man::maketoc}
\sec{name}{NAME}
\NAME{mcxconvert}{convert between mcx storage types}
\sec{synopsis}{SYNOPSIS}
\par{
\mcx{convert} matrix-file-in matrix-file-out\|
\mcx{convert} [--write-binary] --cone-to-stack cat-file-in cat-file-out\|
\mcx{convert} [--write-binary] --stack-to-cone cat-file-in cat-file-out
}
\disclaim_mcx{convert}
\par{
\mcx{convert}
\synoptopt{--cone-to-stack}{transform cone file to stack file}
\synoptopt{--stack-to-cone}{transform stack file to cone file}
\synoptopt{--write-binary}{output native binary format}
\synoptopt{--cat}{read and write cat format}
\synoptopt{-cat-max}{num}{limit the stack conversion to num matrices}
}
\par{
In the two-argument invocation without additional arguments, \mcx{convert}
converts from the format found in the first file to the other format, i.e.
from native interchange to native binary format or the other way around.
When
querying with the \genopt{-q} option, mcx{convert} will output a one-line
synopsis describing the matrix in the argument. The
\genopt{--cone-to-stack} and \genopt{--stack-to-cone} options convert
between the two types of concatenated output provided by \mclcm.
}
\sec{description}{DESCRIPTION}
\par{
The \mcl libraries make extensive use of matrices. Matrices
are used to encode graphs, matrices and clusterings.
They can be stored either in interchange or in binary format. The latter is
somewhat more efficient in storage and much faster in both reading and
writing, but the default is interchange format.
}
\par{
The \mcl input routines recognize the type of storage they are dealing
with. If you want to convert a matrix to the other storage type,
simply specify the file name of the matrix you want to convert.
\mcx{convert} will recognize its type, and write the other type
to the file specified as the second argument.
}
\sec{options}{OPTIONS}
\'begin{itemize}{\mcx_itemopts}
\item{\defopt{--cone-to-stack}{transform cone file to stack file}}
\car{
This option requires two trailing options, the names of respectively the
source cone file and the target stack file.}
\item{\defopt{--stack-to-cone}{transform stack file to cone file}}
\car{
This option requires two trailing options, the names of respectively the
source stack file and the target cone file.}
\item{\defopt{--cat}{read and write cat format}}
\item{\defopt{-cat-max}{num}{limit the stack conversion to num matrices}}
\item{\defopt{--write-binary}{output native binary format}}
\car{
This option is only useful with either of the options
\genoptref{--cone-to-stack},
\genoptref{--stack-to-cone}, or \genoptref{--cat}.
}
\'end{itemize}
\sec{author}{AUTHOR}
\par{
Stijn van Dongen.
}
\sec{seealso}{SEE ALSO}
\par{
\mysib{mcxio},
and \mysib{mclfamily} for an overview of all the documentation
and the utilities in the mcl family.
}
\man::postamble
