Re: innd won't start on my ELF converted machine
I am sending this to the devel list, assuming that not many others have converted to ELF yet. Anyway, the subject says alot. I have had innd running on my system for sometime. After loading all of the new ELF and A.OUT libs, innd doesn't start. I get a message in the log that says: inndstart: inndstart cant bind Address already in use So I thought I would rebuild. First I tried with elf and that failed (sorry I don't remember why at the moment) and then with a.out. The a.out build went fine, but I get the same message. Any ideas? I haven't dug to deeply yet, that's next. But I thought I would ask and maybe not have to solve something someelse already did. Hmmm, I dont see why that's happened. I just converted from a.out to elf yesterday and just restarted innd and it's fine. I get that message from inndstart when it's already runnign and decide to run it again however. Have you checked to see if there's any leftover processes by news when it's not running? Regards, ...Karl -- | PO Box 828 Office: (09)316-3036 Fax: (09)381-3909 |OWER INTERNET SERVICES Canning Bridge After Hours: 015-779-828 WA, 6153 Sales Support: [EMAIL PROTECTED] Internet Service Providers and Networking Solutions
Bug#1897: apropos not resilient to index.db corruption
Package: man
Version: 2.3.10-2
'man -k' and 'apropos' with a damaged or corrupted index.db
segfaults. This is not a very friendly error message.
I have traced the problem to the following piece of code:
whatis.c
364: /* scan for the page, print any matches */
365: static int apropos(char *page, char *lowpage)
366: {
367:datum key, cont;
368:int found = 0;
369:
370: #ifndef BTREE
371:datum nextkey;
372:
373:key = MYDBM_FIRSTKEY(dbf);
374:while (key.dptr) {
375:if (*key.dptr != '$') {
376:cont= MYDBM_FETCH(dbf, key);
377: #else /* BTREE */
378:int end;
379:
380:end = btree_nextkeydata(dbf, key, cont);
381:while (!end) {
382:if (*key.dptr != '$') {
383: #endif /* !BTREE */
384:if (*cont.dptr != '\t') { /* a real page */
--
If the database is corrupted, then it is possible to read off the end
of the database without seeing a '$' (line 375), and calling
MYDBM_FETCH() when there isn't any data to fetch. This makes 'cont'
NULL (line 376), which gets dereferenced in line 384. Kaboom,
segfault.
Could this infelicity be passed on to the upstream maintainer, please
?
The problem with just checking for null is that this is very likely
not the only place where things can go wrong.
Also, it might be nice to have a database consistancy checker, that
would tell you if a given database were consistant.
Austin
Some questions concerning further sysklogd upload
Hi folks! We (Greg and myself) are now at a late stadium right before releasing 1.3 of our sysklogd package. To have a smooth introtuction I have to get some answers to some questions before can it for debian I have. Hopefully the maintainers are willing to answer. :-) 1. Who is responsible for kernel versions? If you use a kernel version less than 1.3.43 you'll need to apply a patch. So I probably need to know the maintainers of the 1.2.x and 1.3.y versions. 2. Who is responsible for entries in the /etc/services file? 3. How do I get a possibly non-existing manpage removed within the installation procedure? Have a nice weekend anyway, Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / +49-441-777884 * LoginPasswd: nuucp * Index: ~/ls-lR.gz / / This copy of Netscape has expired. -- Netscape / /Ein weiterer Grund Mosaic zu benutzen. :-( /
Bug#1898: getwd(3) contains falsehood
Package: manpages Version: 1.8-1 getwd(3) claims: getwd, which is only prototyped if __USE_BSD is defined, will malloc(3) an array big enough to hold the absolute pathname of the current working directory. However, the libc Info page says: - Function: char * getwd (char *BUFFER) This is similar to `getcwd', but has no way to specify the size of the buffer. The GNU library provides `getwd' only for backwards compatibility with BSD. The BUFFER argument should be a pointer to an array at least `PATH_MAX' bytes long (*note Limits for Files::.). In the GNU system there is no limit to the size of a file name, so this is not necessarily enough space to contain the directory name. That is why this function is deprecated. Experience seems to suggest that the libc Info page is right and the manpage is wrong, at least if you pass a non-null argument to getwd. The manpage should be changed to say that getwd is deprecated. Ian.
Bug#1897: apropos not resilient to index.db corruption
Hi Austin, Package: man Version: 2.3.10-2 'man -k' and 'apropos' with a damaged or corrupted index.db segfaults. This is not a very friendly error message. I have traced the problem to the following piece of code: ... Could this infelicity be passed on to the upstream maintainer, please ? Thankyou for your effort it is much appreciated - I will indeed forward this bug report on to the Wilf - the man_db creator. Also, it might be nice to have a database consistancy checker, that would tell you if a given database were consistant. Yes indeed - it might not be too hard to write. For the present it is not to hard to recreate the database if it is corrupted using mandb. Maybe the daily man cron job should recreate the database from scratch every night. The problem being that the database and the mandb program are not something common to all unix systems and mandb is initially run for the user by the post install script. Thus when something does go wrong users dont know where to look to fix things. A core dump doesnt immediately suggest the fix is to run the mandb program. I have heard several other people say they have had corrupt database files - how do they get corrupted? I have never managed to corrupt mine (but then I, as the package maintainer, wouldnt would I) alvar -- Alvar Bray Meiko LimitedPhone:+44 1454 616171 650 Aztec West Fax: +44 1454 618188 Bristol BS12 4SD E-Mail: [EMAIL PROTECTED] England WWW: http://www.meiko.com Via: Debian GNU/Linux from home.
Re: Bug#1895: run-parts does not run scripts without #!/...
I think I am going to rewrite run-parts in C. I don't know perl and don't have the time to learn it just to fix run-parts. :) Jeff Harald Schueler writes (Bug#1895: run-parts does not run scripts without #!/...): Package: miscutils Version: 1.3-5 Run-parts does not run scripts not beginning with #!/... This may not be a bug, but it should be documented. run-parts --test, however, displays _all_ scripts, which is rather confusing, and not a test at all. It does run them - or try to, anyway. It invokes `system' in Perl. Unfortunately Perl does the wrong thing when you say $foo='./t'; system($foo './u'); if ./t isn't a proper executable script. IMO it should produce a message to stderr, but it doesn't. Instead $? is set to 62580 and no message is produced. Ian.
Bug#1897: apropos not resilient to index.db corruption
On Sat, 25 Nov 1995, Alvar Bray wrote: [...] I have heard several other people say they have had corrupt database files - how do they get corrupted? I have never managed to corrupt mine (but then I, as the package maintainer, wouldnt would I) I have no idea how mine got corrupted, sorry :( Austin
Bug#1897: apropos not resilient to index.db corruption
Alvar Bray: I have heard several other people say they have had corrupt database files - how do they get corrupted? I have never managed to corrupt mine (but then I, as the package maintainer, wouldnt would I) I imagine one technique might be to have the file system get full during a database update. Alternatively, a loose drive connector might do it. -- Raul
inline-math-1.7 (fwd)
I haven't taken a look it this yet, but would we want to replace the mathematical functions mentioned below with these new routines? I caught this, and I believe that it points out a flaw (minor) in GCC, and improvements to the math functions. Ideas, comments, flames? --D.J. Gregor, quiet Debian maintainer... [EMAIL PROTECTED] -- Here's the message from comp.os.linux.announce --- From: John Bowman [EMAIL PROTECTED] Newsgroups: comp.os.linux.announce Subject: inline-math-1.7 Date: Sat, 25 Nov 95 15:23:45 GMT -BEGIN PGP SIGNED MESSAGE- Version 1.7 of inline-math has been uploaded to sunsite: /pub/Linux/libs/inline-math-1.7.tar.gz. Inline-math is a set of gcc inlined floating-point math routines that can typically improve execution speed by 10%. These routines avoid using the flawed algorithms for sinh, tanh, asinh, and atanh found in libm (which produce incorrect results for small arguments). The new version intefaces better with GCC to avoid producing code that can overflow the register stack in complex routines. Specifically, exp(), expm1(), and atan2() were rewritten. Inlined versions of pow(), ceil(), floor(), and the math extensions log2() and pow2() were also added. John Bowman [EMAIL PROTECTED] Institute for Fusion Studies, RLM 11.222 The University of Texas at Austin Austin, TX 78712 -BEGIN PGP SIGNATURE- Version: 2.6.2i iQCVAwUBMLczg4QRll5MupLRAQEucQQA2W52fkUIJdDJsowpo7YbCkYNG+hZ5K9/ fOWNPzzBek0i/Ke6OBmg1k+NbqHb69VhC71BXC9cXcCPamVO0gfnpPiX4mPB7uOl uDNmFwb470oODrPAzea7m2jTGtdPLmc6e+I9mZxSp9DRH0JmfiZnFvHN+v2dlN9X XlNaiSoZ29I= =BMm/ -END PGP SIGNATURE- -- This article has been digitally signed by the moderator, using PGP. Finger [EMAIL PROTECTED] for PGP key needed for validating signature. Send submissions for comp.os.linux.announce to: [EMAIL PROTECTED] PLEASE remember a short description of the software and the LOCATION. --- end of forwarded message ---
Bug#1897: apropos not resilient to index.db corruption
Alvar Bray: I have heard several other people say they have had corrupt database files - how do they get corrupted? I have never managed to corrupt mine (but then I, as the package maintainer, wouldnt would I) Possibly a SIGINT, SIGQUIT, SIGTERM, SIGKILL at an inopportune time.
