Bug found - Re: Needing a debug version of setup.exe

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug found - Re: Needing a debug version of setup.exe

Doug Wyatt

First, my thanks to Igor Pechtchanski for reminding me that
there is a firewall between me and the CVS server.  I had no
problem getting the source, from outside the firewall.

I built a debug version of setup.exe and used that to find
the problem in the setup.ini generated for a repository we
maintain on our company LAN.

What I found was that a 'source:' line without either a
preceding 'version:' or 'install:' line in the package entry
will cause setup.exe to crash.

In my case, it was an old gperf source package that did not
have a version number that led to the problem (no 'version:'
line was generated by upset).  But, the issue can be duplicated
in the gcc-testsuite package entry by just commenting-out a
'version:' line in setup.ini; or in any other package entry, by
commenting-out the 'version:' and 'install:' lines, leaving the
'source:' entry for a particular version number.

My apologies for not being able to offer a patch.  It's been
a *very* long time since I last constructed a YACC grammar or
action routines for one.  I don't even know that the developers
will even consider this to be a bug. It's certainly not a
serious one.

Regards,
Doug Wyatt

Reply | Threaded
Open this post in threaded view
|

Re: Bug found - Re: Needing a debug version of setup.exe

Igor Peshansky
On Fri, 30 Dec 2005, Doug Wyatt wrote:

> First, my thanks to Igor Pechtchanski for reminding me that
> there is a firewall between me and the CVS server.  I had no
> problem getting the source, from outside the firewall.
>
> I built a debug version of setup.exe and used that to find
> the problem in the setup.ini generated for a repository we
> maintain on our company LAN.
>
> What I found was that a 'source:' line without either a
> preceding 'version:' or 'install:' line in the package entry
> will cause setup.exe to crash.
>
> In my case, it was an old gperf source package that did not
> have a version number that led to the problem (no 'version:'
> line was generated by upset).  But, the issue can be duplicated
> in the gcc-testsuite package entry by just commenting-out a
> 'version:' line in setup.ini; or in any other package entry, by
> commenting-out the 'version:' and 'install:' lines, leaving the
> 'source:' entry for a particular version number.
>
> My apologies for not being able to offer a patch.  It's been
> a *very* long time since I last constructed a YACC grammar or
> action routines for one.  I don't even know that the developers
> will even consider this to be a bug. It's certainly not a
> serious one.

FWICS, it's not the parser code that's causing this.  The crash is
ultimately caused by line 147 in IniDBBuilderPackage.cc
(IniDBBuilderPackage::buildPackageSource), where it tries to assign the
canonical version of the binary package to the canonical version of the
source package.  This ends up trying to decode the canonical version,
which is not initialized.  I'd say the above function is buggy, rather
than the parser, and any fix should be attempted there (e.g., extracting
the version information from the source name if the binary package is not
initialized).
HTH,
        Igor
--
                                http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_    [hidden email] | [hidden email]
ZZZzz /,`.-'`'    -.  ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-' old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"