setup.exe dies in dumpAndList()

[Charles Wilson]

I ran into a problem when I was attempting to test the 
postinstall/preremove behavior of my new inetutils port. In order to 
duplicate the end-user experience, I created a local site with a 
setup.ini file:

=============================================================
./:
do_genini*  genini*  release/  setup.ini

./release:
inetutils/

./release/inetutils:
inetutils-1.3.2-37-src.tar.bz2  inetutils-1.5-1-src.tar.bz2  setup.hint
inetutils-1.3.2-37.tar.bz2      inetutils-1.5-1.tar.bz2
=============================================================


Where I used genini to create the setup.ini.  What happened was that 
when I ran setup.exe, I got to the chooser and my package wasn't there! 
On a whim, I figured maybe I needed more "stuff", so I pulled in my 
recent tcp_wrappers, AND built a debug version of setup.exe, with 
-DDEBUG turned on.


=============================================================
./:
do_genini*  genini*  release/  setup.ini

./release:
inetutils/  tcp_wrappers/

./release/inetutils:
inetutils-1.3.2-37-src.tar.bz2  inetutils-1.5-1-src.tar.bz2  setup.hint
inetutils-1.3.2-37.tar.bz2      inetutils-1.5-1.tar.bz2

./release/tcp_wrappers:
libwrap-devel/  tcp_wrappers-7.6-2-src.tar.bz2  tcp_wrappers-7.6-4.tar.bz2
libwrap0/       tcp_wrappers-7.6-2.tar.bz2
setup.hint      tcp_wrappers-7.6-4-src.tar.bz2

./release/tcp_wrappers/libwrap-devel:
libwrap-devel-7.6-4.tar.bz2  setup.hint

./release/tcp_wrappers/libwrap0:
libwrap0-7.6-4.tar.bz2  setup.hint
=============================================================


And that's when things got really interesting.  It seems that the 
inetutils fragment of setup.ini IS getting parsed, but when you hit the 
next fragment, the constructor for the new IniDBBuilderPackage calls 
dumpAndList on the OLD entry (but only if -DDEBUG).

Ordinarily, this is nice: it prints a lot of information about how the 
ini file was parsed to the setup.log.full file.  In this case, however, 
it exposes in a much more dramatic way what was causing my earier 
problems with this setup.ini: in *this* case, I get what is, I think, a 
NULL pointer access in dumpAndList -- which means that the structure 
created to describe the inetutils package is improperly constructed -- 
and THAT is why inetutils didn't show up in the chooser; I surmise that 
the chooser is smart enough to skip over entries that have null 
values...but dumpAndList is not:

void
dumpAndList (vector<vector <PackageSpecification *> *> const 
*currentAndList,
              std::ostream &logger)
{
<<<<<  A  >>>>>>>
   if (currentAndList)
   {
     vector<vector <PackageSpecification *> *>::const_iterator iAnd =
       currentAndList->begin();
     while (true)
     {
       if ((*iAnd)->size() > 1) log (LOG_BABBLE) << "( ";
       vector<PackageSpecification *>::const_iterator i= (*iAnd)->begin();
       while (true)
       {
         log(LOG_BABBLE) << **i;
         if (++i == (*iAnd)->end()) break;
         log(LOG_BABBLE) << " | ";
       }
       if ((*iAnd)->size() > 1) log (LOG_BABBLE) << " )";
       if (++iAnd == currentAndList->end()) break;
       log (LOG_BABBLE) << " & ";
     }
   }
<<<<<  B  >>>>>>>
}

Somewhere between A and B, I get a "Do you want to report to 
Microsoft"/"terminated in an unusual way" popup.

And that's far as I got.  I have attached the offending setup.ini and 
setup.hint -- but to recreate this error, you'd also need my actual 
local directory tree.  If someone is really interested in tracking this 
down, I can send that via private email or a website.

=============================================================
Now begins the rant:

What in the name of all that is holy possessed the person that designed 
the logging behavior of setup.exe?  What kind of sense does it make to 
store the ENTIRE CONTENTS of the log in MEMORY, and only dump it to the 
actual file at the very END of the application, just before exit(0) is 
called?

When exit is NOT called -- say, if there is an unhandled exception -- 
then you have NOTHING.  No information AT ALL.  I don't have the WORDS 
to describe how...er, shortsighted...that is.

And never mind the fact that even after building my own debug version of 
setup.exe, I still couldn't get gdb to cooperate: it seemed unable to 
ineteract at all with the inferior.  How do you guys debug this thing? 
Is there some weird incantation necessary to enable gdb to debug a GUI app?

I was reduced to using printf -- actually, even worse: in gui mode there 
is no printf, and I don't know how to intercept OutputDebugString 
without using Visual Studio...so I was ACTUALLY stuck using MessageBox() 
as my only debug tool.  But even THAT would have been OK, if I only had 
useful log files...

</end rant>

--
Chuck


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setup.hint
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20080225/0f656980/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setup.ini
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20080225/0f656980/attachment-0001.ksh>