Title: Re: [Ethereal-dev] Crash issue with compiled version of 0.10.7
Svn revision :
Actually it seems that I had a nightly snapshot (rev 12475) instead of the real 0.10.7 ( which is at the revision 12359 right ?). That was my mistake.
I updated my compilation tree (rev 12488) and now ethereal doesn't crash anymore thanks a lot !
The patch just fixed a build breack on my machine. I am not a preofessional programmer but I have some idea :
- to make the building process more coherent, the path to the tools grep , sed, unzip and wget should be defined in config.nmake instead of a direct reference to the executable in the Makefile.nmake. The main reason is that on a windows machine , the utility GNU which v2.4 is not able to find the tool without its extension : which grep doesn't reply anything but which grep.exe does.
- in the file tools/win32-setup.sh, the cygpath utility is used with "--unix" flag, which looks weird on a windows machine. Moreover the change fixes an unzip error with the "setup" target
# DEST_PATH=`cygpath --unix "$2"`
DEST_PATH=`cygpath --windows "$2"`
Output with DEST_PATH=`cygpath --unix "$2"` :
Downloading gtk2.4/glib-2.4.7.zip into /cygdrive/c/ethereal-win32-libs, installing into glib
File `glib-2.4.7.zip' already there, will not retrieve.
Extracting /cygdrive/c/ethereal-win32-libs/glib-2.4.7.zip into /cygdrive/c/ethereal-win32-libs/glib
unzip: cannot find either /cygdrive/c/ethereal-win32-libs/glib-2.4.7.zip or /cygdrive/c/ethereal-win32-libs/glib-2.4.7.zip.zip.
ERROR: Couldn't unpack /cygdrive/c/ethereal-win32-libs/glib-2.4.7.zip
Output with DEST_PATH=`cygpath --windows "$2"` :
Downloading gtk2.4/glib-2.4.7.zip into C:\ethereal-win32-libs, installing into glib
File `glib-2.4.7.zip' already there, will not retrieve.
Extracting C:\ethereal-win32-libs/glib-2.4.7.zip into C:\ethereal-win32-libs/glib
Verifying that the DLLs in C:\ethereal-win32-libs/glib are executable.
Date: Wed, 03 Nov 2004 11:20:31 -0800
From: Guy Harris <gharris@xxxxxxxxx>
Subject: Re: [Ethereal-dev] Crash issue with compiled version of
0.10.7
To: Ethereal development <ethereal-dev@xxxxxxxxxxxx>
Message-ID: <41892F7F.1030105@xxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Jeremy Jouglet wrote:
> I have a crash issue with the enclosed cap file with a fresh compiled
> version of the 0.10.7, the official binaries are working very well.
Do you have a freshly compiled 0.10.7, or you have something compiled
from SVN or an SVN snapshot from after 0.10.7 was released?
> Any idea of what I have done wrong ?
Assumed that the eDonkey dissector was being careful enough about the
packets it was dissecting.
It appears that there's an eDonkey packet in that capture (it has the
right protocol code at the beginning of the TCP data), but the length
field appears to have a very large value; this caused the computed
message length to overflow (it's 32-bit), which means that a protocol
tree item had its length set to a negative value - 0.10.7 didn't check
for that, but the current verswion of the source does.
I've checked in a change to add support for reassembling eDonkey packets
split across TCP segments; a side-effect of this is that your capture
doesn't cause a crash.
> <<crash.patch>>
That's an unrelated patch - are those changes needed in order to fix a
problem with the Windows build?
It
