setup.exe dies in dumpAndList()
Charles Wilson
cygwin@cwilson.fastmail.fm
Mon Feb 25 05:23:00 GMT 2008
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>
More information about the Cygwin-apps
mailing list