Hello Robert, Wednesday, June 26, 2002, 11:54:05 PM, you wrote:
RC> I've uploaded a new setup.exe snapshot. It's got some major parsing RC> changes... I don't think I've broken anything, but I'd appreciate It seems there is a problem with setup.exe being able to recognize the dependent packages for some of the packages - apache, inetutils. Maybe its the same for all packages but I cant be quite sure. Below I just expose the problem I don't know which code causes it - I guess it is the setup.ini parser. Take a look of he "if" block on Line 571, choose.cc (2.253 snapshot): The dp->package.serialise () method returns the 'ldesc' of the parent package itself for all the dependencies (i.e. the for loop) - see below: 578 (gdb) next 575 String requires = dp->package.serialise (); (gdb) step PackageSpecification::serialise (this=0x1287b24) at PackageSpecification.cc:54 54 { (gdb) next 55 return _packageName; (gdb) p _packageName $30 = {theData = 0x1287860} (gdb) p *_packageName.theData $31 = {count = 1, theString = 0x1287888 "The Apache Project is a collaborative software developm ent\neffort aimed at creating a robust, commercial-grade, featureful,\nand freel y-available source code implementation of an HTTP (Web)\nserver. The"..., cstr = 0x0, length = 639} This taken itself is wrong - to add more, there is a nasty side effect :) With the apache package it causes the stack being seriosly overwritten in the call to msg() (called via engLog manipulator), where a buffer with fixed size of 1000 is allocated on the stack: (gdb) step operator<< (os=@0x49f974, theString=@0x22ee64) at String++.cc:260 260 os << theString.cstr_oneuse(); (gdb) p theString.theData $44 = (_data *) 0x1fc6cf8 (gdb) p *theString.theData $45 = {count = 1, theString = 0x1fd30a0 "The Apache Project is a collaborative software developm ent\neffort aimed at creating a robust, commercial-grade, featureful,\nand freel y-available source code implementation of an HTTP (Web)\nserver. The"..., cstr = 0x0, length = 1280} (gdb) This buffer with a length of 1280 will later corrupt the stack :) The size is 1280 because we have 2 dependencies, for which, as explained above, we get the 'ldesc' of the parent.