> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb74338c0 (LWP 2780)]
> csscompress (filename=0xbfa1f91f "/home/julien/eric.css") at csscompress.c:150
> 150 csscompress.c: No such file or directory.
> in csscompress.c
> (gdb) bt
> #0 csscompress (filename=0xbfa1f91f "/home/julien/eric.css") at
> csscompress.c:150
> #1 0x0804ad9a in main (argc=Cannot access memory at address 0x166d56d2
> ) at csscompress.c:89
> (gdb) s
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> The program no longer exists.
> (gdb) quit
>
>
> I hae no idea how to read these results..
> I'd appreciate your comments on the various points above.
Some additional information:
- I have attempted several times to restart dspam's training from scratch (that
is, with fresh new css files). It always ends like this, with segmentation
faults in the tools. So, it's very reproducible, and it is not the css file
that got "accidentally corrupted".
- I have the *impression* it is linked to the size of the css file. It *looks
like* the css tools have a problem of recursion when there are too many levels
of nodes in the hash file. These statements are purely conjectural, though, I
cannot prove them.
- I don't consider the answer "hash backend is buggy, don't use it" as a valid
solution to this problem. :-)
- Sample of faulty file is here : http://www.bureau-cornavin.com/eric.css
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Dspam-devel mailing list
Dspam-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-devel
