On Fri, Feb 18, 2000 at 09:00:07AM +0100, Lars Knudsen wrote:
> Grettings..
>
> I tried to print to a file and got a core file. On req. I did a "gdb
> ethereal core" (which is a great tool.. thanks .. didn´t know that it
> existed(stupid me)) and this is what i got..
>
> -----------------------
> Reading symbols from /usr/lib/ethereal/plugins/0.8/gryphon.so...done.
> #0 _IO_fputs (
> str=0xbfffee38 " 37 14:35:12.2615 129.142.7.100
> 130.228.222.123 DNS Standard query response CNAME www.sol.no A
> 195.225.3.46 A 195.225.2.59 A 195.225.3.50 A 195.225.2.37 A 195.225.3.37 A
> 195.2"..., fp=0x0)
> at iofputs.c:39
> 39 iofputs.c: No such file or directory.
(Moving discussion to "ethereal-dev", as it's a discussion of the cause
of a bug.)
Try typing "backtrace" in GDB, and sending us the output; that'll show
the routine that called "_IO_fputs()", and the routine that called that
routine, and so on.
Also, which version of Ethereal is this? If "_IO_fputs()" is what's
ultimately called when "fputs()" is called, this shouldn't be happening,
at least in the current version of Ethereal in the CVS tree, as the only
place "fputs()" gets called in the packet printing code is from
"print_line()", called from "print_packets()", and "print_packets()"
returns if it fails to open the file (or to open a pipe to the print
program), rather than passing a null pointer on to "print_line()" - but
it looks as if a null pointer was passed to "_IO_fputs()" ("fp=0x0").
Perhaps the code path is different in the version of Ethereal you're
using.
