Re: howto debug unzip under cygwin?

Thanks for your assistance, 2 more questions:

0 how to set GDB to catch unzip problems like

Thomas L Roche 02/12/2004 02:50 PM
>> >   inflating:
>> 
/d/eclipse/builds/20040121_1953-WB213-AD-V512D-00/eclipse/plugins/com.ibm.etools.j2ee.ui/build/pluginBuild/commonbld/com/ibm/etools/ejb/ui/presentation/EJBEditorOutlineContentProvider.class

>> >     735 [main] unzip 1820 cmalloc: cmalloc returned NULL
>> > error:  zipfile probably corrupt (segmentation violation)

1 who's the maintainer(s) for the Cygwin port of unzip, and how to
  contact her/him/them?

? Why I ask:

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

Greg Roelofs 02/13/2004 02:34 AM
> It appears that unzip-5.50-5.sh is the key. See how it's invoking
> the compiler when given "build" as an argument, and add -g to the
> command line somehow (e.g., to CFLAGS or even the definition of CC).

Actually that was there, already: 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 in gdb was

* 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

> # 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! But I'm wondering: where or how should I set GDB
to break so as to get useful information about the problem?

>> Also, I'd appreciate information about 

>> * 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.

OK, but they're list is very-high-volume, and they're not (in my
humble experience) the most helpful lot. Is there a maintainer for the
Cygwin port of unzip whom I could contact?