Re: css* tools segfault

> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspam-devel