Re: Patches for various crashers
Jason Gunthorpe wrote:
On Wed, 26 Sep 2001, Christoph Pfisterer wrote:
>I think some of them I already found for 0.5.4, at least the tag file ones
>sound familiar..
No, all of the problems are still there. I'll send a patch against
CVS HEAD when I have one.
Oh? Hm.
Okay, here's the patch for tagfile.(cc|h):
Index: tagfile.cc
===================================================================
RCS file: /cvs/deity/apt/apt-pkg/tagfile.cc,v
retrieving revision 1.30
diff -u -r1.30 tagfile.cc
--- tagfile.cc 2001/05/14 05:56:26 1.30
+++ tagfile.cc 2001/10/03 09:50:46
@@ -197,7 +197,7 @@
return false;
TagCount = 0;
- while (TagCount < sizeof(Indexes)/sizeof(Indexes[0]) && Stop < End)
+ while (TagCount+1 < sizeof(Indexes)/sizeof(Indexes[0]) && Stop < End)
{
// Start a new index and add it to the hash
if (isspace(Stop[0]) == 0)
@@ -211,13 +211,13 @@
if (Stop == 0)
return false;
- for (; Stop[1] == '\r' && Stop+1 < End; Stop++);
+ for (; Stop+1 < End && Stop[1] == '\r'; Stop++);
// Double newline marks the end of the record
if (Stop+1 < End && Stop[1] == '\n')
{
Indexes[TagCount] = Stop - Section;
- for (; (Stop[0] == '\n' || Stop[0] == '\r') && Stop < End; Stop++);
+ for (; Stop < End && (Stop[0] == '\n' || Stop[0] == '\r'); Stop++);
return true;
}
Index: tagfile.h
===================================================================
RCS file: /cvs/deity/apt/apt-pkg/tagfile.h,v
retrieving revision 1.17
diff -u -r1.17 tagfile.h
--- tagfile.h 2001/04/22 05:42:52 1.17
+++ tagfile.h 2001/10/03 09:50:47
@@ -34,7 +34,7 @@
// We have a limit of 256 tags per section.
unsigned short Indexes[256];
- unsigned short AlphaIndexes[0xff];
+ unsigned short AlphaIndexes[0x100];
unsigned int TagCount;
and the patch for cmdline/apt-cache.cc:
Index: apt-cache.cc
===================================================================
RCS file: /cvs/deity/apt/cmdline/apt-cache.cc,v
retrieving revision 1.52
diff -u -r1.52 apt-cache.cc
--- apt-cache.cc 2001/07/02 00:10:32 1.52
+++ apt-cache.cc 2001/10/03 09:54:35
@@ -374,8 +374,10 @@
if (ReadPinFile(Plcy) == false)
return false;
- pkgCache::VerFile **VFList = new pkgCache::VerFile
*[Cache.HeaderP->PackageCount];
- memset(VFList,0,sizeof(*VFList)*Cache.HeaderP->PackageCount);
+ // Make sure we have a sentinel for the list.
+ unsigned long Count = Cache.HeaderP->PackageCount+1;
+ pkgCache::VerFile **VFList = new pkgCache::VerFile *[Count];
+ memset(VFList,0,sizeof(*VFList)*Count);
// Map versions that we want to write out onto the VerList array.
for (pkgCache::PkgIterator P = Cache.PkgBegin(); P.end() == false; P++)
@@ -428,7 +430,7 @@
VFList[P->ID] = VF;
}
- LocalitySort(VFList,Cache.HeaderP->PackageCount,sizeof(*VFList));
+ LocalitySort(VFList,Count,sizeof(*VFList));
// Iterate over all the package files and write them out.
char *Buffer = new char[Cache.HeaderP->MaxVerFileSize+10];
> Unfortunately, Darwin is not a very friendly place to live in. I had
to do some "bad hacks" to compensate for breakage in the C library
and the C++ runtime. Since Darwin doesn't use ELF and apt doesn't use
Not using ELF? That's almost unforgivable :P
To be honest, I've grown fond of Mach-O. Almost everything it does is
quite sensible, it just happens to be different from how it's done in
the ELF world (and no one dares change ELF, because it will break
everything...). For example, it has actual minor version checking for
shared libraries and distinguishes between shared libraries and
loadable modules. It also encourages people to put version numbers
between the library name and the extension (allowing for instance
"-lgdbm.2"), but doesn't get in the way if you still want to tack it
on behind the extension. Unfortunately, most of this comes as a
surprise to many programs...
I dislike libtool intensely, but it should be possible to make it used
conditionally fairly easially. Then again, if all it takes is a few lines
in environment.mak then there probably is no point.
I also dislike libtool (especially after trying to get it working
100% on Darwin and failing at 90%). Actually I really, really dislike
anything that uses mass quantities of shell commands, i.e. the whole
autoconf, automake and libtool toolchain, and non-trivial Makefiles
in general. I'd be writing a proper replacement right now if I had
the time. ;-) Unfortunately, those tools get their job done most of
the time (so there's no urgent need to replace them) and to my
knowledge libtool is the only one of its kind.
As for adapting environment.mak - it's not that easy unfortunately.
Mach-O uses a different extension (.dylib) and likes to put version
numbers before the extension, i.e. "libfoo.4.7.dylib" instead of
"libfoo.so.4.7". It also needs some special flags to encode the minor
version and the full path to the lib into the library. So I guess
adding optional libtool support is easier than adapting for all this
in your build system. Support for using an already installed libtool
command (like ncurses does it) is fine BTW, no need to add the whole
stuff to your configure script. Let me know if I can be of assistance
with this.
> library. I'll try to come up with a patch for that last one;
referencing debSystem alone is not enough.
Do C++ global ctors work at all on darwin? If it's not using ELF it is
difficult to say how the ctor mechanism works, which might explain why
that trick doesn't do it for you.
The global ctors work, but apparently they're only called when the
class is first referenced. After all, apt wouldn't work if the ctors
were broken completely, or am I missing something?
Other stuff that breaks on Darwin: flushing standard output doesn't
work as expected (had to insert fflush()'s), Apple recently broke
mmap(), getaddrinfo() is broken as well (the headers even more so),
there's a conflict between Makefile and makefile because the default
file system is case-insensitive, and the socket functions don't like
unsigned ints (there's no socklen_t of course). I can only hope that
Apple cleans up the NextStep heritage some day...
Hope this helps,
-chrisp
--
chrisp a.k.a. Christoph Pfisterer "Any sufficiently advanced
cp@chrisp.de - http://chrisp.de bug is indistinguishable
PGP key & geek code available from a feature."
Reply to: