Bug#493624: zoem: segmentation fault during translation to html

2008-08-22 Thread Tobias Quathamer
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

2008-08-12 Thread Tobias Quathamer
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

2008-08-04 Thread Tobias Quathamer
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

2008-08-04 Thread Philipp Benner
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

2008-08-04 Thread Tobias Quathamer
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

2008-08-03 Thread Philipp Benner
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