debugging unzip

[Thomas L Roche <tlroche at us dot ibm dot com>]

How to setup gdb (and cygwin1.dll) to catch unzip problems like

>   inflating: 
eclipse/plugins/com.ibm.etools.utc/IBMUTC/IBMUTC.ear/UTC.war/WEB-INF/classes/com/ibm/etools/utc/property/PropertyFormat.class 
 
>    1011 [main] unzip 1120 cmalloc: cmalloc returned NULL

> Program received signal SIGSEGV, Segmentation fault.
> 0x610cac74 in memcpy () from /usr/bin/cygwin1.dll

? Why I ask:

Thomas L Roche 02/11/2004 06:08 PM
>>> it seems pretty clear to me that something "down deep" in the base
>>> broke after 1.5.5-1:

>>> 0 both character-mode (e.g. unzip) and X (e.g. emacs) apps are
>>>   broken

>>> 1 inputs that worked in 1.5.5-1 don't work now

>>> 2 failures are intermittent and apparently random

>>> 3 error messages suggest malloc problems 

>>> Am I missing something?

Christopher Faylor Wed, 11 Feb 2004 18:45:42 -0500
>> Actual debugging of the problem, with a debugger?

Thomas L Roche 02/11/2004 11:14 PM (heavily edited)
> I do

> wget -O - 
ftp://mirrors.rcn.net/pub/sourceware/cygwin/release/unzip/unzip-5.50-5-src.tar.bz2 
| tar -C /usr/src -xj
> cd /usr/src && ./unzip-5.50-5.sh prep && ./unzip-5.50-5.sh conf && 
./unzip-5.50-5.sh build && ./unzip-5.50-5.sh install
> cd /usr/src/unzip-5.50/.inst && gdb --args ./usr/bin/unzip.exe 
/d/eclipse/zips/wsa-jdk-20040210_1925-WB213-AD-V512D-W5.zip

> and get

> > This GDB was configured as "i686-pc-cygwin"...(no debugging
> > symbols found)...

The problem was stripping: 4 years of Java, 2 years of Perl, and I
have totally forgotten the thrill of linkage :-( For future reference
by the next poor bastard in my situation, what I did to see symbols:

* run (from bash)
  cd /usr/src
  rm -fr unzip*
  cd /
  wget -O - 
ftp://mirrors.rcn.net/pub/sourceware/cygwin/release/unzip/unzip-5.50-5-src.tar.bz2 
| tar -C /usr/src -xj
  cd /usr/src

* edit /usr/src/unzip-5.50-5.sh (no unix/Makefile yet)
> # MY_CFLAGS="-O2 -g"
> MY_CFLAGS="-O2 -ggdb"

  -g would probably have been OK, though. I also commented out

> # strip() {
> #   (cd ${instdir} && \
> #   find . -name "*.dll" | xargs strip > /dev/null 2>&1
> #   find . -name "*.exe" | xargs strip > /dev/null 2>&1
> #   true
> # )}

  just to be sure.

* run
./unzip-5.50-5.sh prep

* now edit /usr/src/unzip-5.50/unix/Makefile

> cygwin:   unix_make
>   $(MAKE) unzips CC?=gcc LD?=gcc CRC32=crc_cygwin \
> #   CF="-O2 -I$(SRC) -DUNIX -DASM_CRC -DHAVE_TERMIOS_H -DDIRENT" \
> #   CP=cp LN="ln -s" LF2=""
>   CF="-ggdb -O2 -I$(SRC) -DUNIX -DASM_CRC -DHAVE_TERMIOS_H -DDIRENT" \
>   CP=cp LN="ln" LF2=""

  Note that the above was not enough, there was also (very annoyingly)

> # INSTALL_PROGRAM = install -s -m $(BINPERMS)
> INSTALL_PROGRAM = install -m $(BINPERMS)

* run
./unzip-5.50-5.sh conf && ./unzip-5.50-5.sh build && ./unzip-5.50-5.sh 
install
cd /usr/src/unzip-5.50/.inst && gdb --args ./usr/bin/unzip.exe 
/d/eclipse/zips/wsa-jdk-20040210_1925-WB213-AD-V512D-W5.zip

Now I see symbols, and can run in gdb, at which point I get the trace

>   inflating: 
eclipse/plugins/com.ibm.etools.utc/IBMUTC/IBMUTC.ear/UTC.war/WEB-INF/classes/com/ibm/etools/utc/property/PropertyFormat.class 
 
>    1011 [main] unzip 1120 cmalloc: cmalloc returned NULL

> Program received signal SIGSEGV, Segmentation fault.
> 0x610cac74 in memcpy () from /usr/bin/cygwin1.dll

I'm wondering: what/how should I set in gdb to break so as to get
useful information about the problem? I'm suspecting this will require
also {building from source, debugging} cygwin1.dll: pointers toward
that end would also be appreciated.

FWIW I got the following advice on the info-zip list:

http://lists.wku.edu/pipermail/info-zip/2004-February/000193.html
>> * the plausibility of my hypothesis. I suspect there is a problem
>>   in the new cygwin's malloc code: something that formerly did not
>>   return NULL now does, which is choking unzip. Does this sound
>>   reasonable?

> Yes. UnZip should have failure checks for all malloc/calloc calls,
> but it's possible that the calloc() failure is triggering other
> problems or is itself triggered by a larger problem that is also
> causing other badness to occur.

>> * where should I look for the underlying malloc code (cygwin1.dll?
>>   libc*?), and how should I build/debug that?

> No clue.  The Cygwin folks will have to answer that.

Your help would be appreciated! I am trying to do my part:
unfortunately I have little experience debugging with GNU tools.
(Or debugging GNU tools, for that matter.)

Feel free to forward, and to reply directly to me (as well as to the
list). Your prompt assistance is appreciated, Tom Roche


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/