irclog2html for uclibc on 2002.08.25

14:09:20tzangermorning
14:11:03mjn3morning
19:41:28mjn3andersee: hey.  testing a fix for the perl msg queue stuff.  found and fixed the 2 exit failures as well.  grr...
19:42:34mjn3andersee: the tests that were failing were closing stderr and then "die"ing with a message.  perl tries to output the messages to stderr anyway...
19:44:28mjn3andersee: with the fopencookie stuff enabled (default), i was setting the cookie ptr to NULL on close, as a diagnostic aid.  SUSv3 says fwrite can return EBADF in such a case...
19:46:54mjn3andersee: it was easy enough to fix for closed files, but following the logic someone could say that all FILE *'s should be checked out as refs to valid files.  i think that would generate a lot of overhead for something you shouldn't be doing.
19:53:48mjn3andersee: ok.. found the problem and my test fix seems to work on i386.  common/bits/msq.h defines struct msqid_ds as glibc does... not as the kernel does.  defining it in a kernel-compatible manner fixes the last perl sysvipc test failure
19:55:01anderseecool.
19:55:52anderseeSo what did you change for the flopencookie stuff?  Just retuen EBADF after files are closes?
19:57:14mjn3no.  i changed it so that fclose sets the cookie * to the address of the FILE fildes member.  that gets set to -1.  and i set the worker functions to the "usual" case.  so, any file ops send a file descriptor of -1 to the kernel, and it handles it
19:57:44mjn3i'll get that checked in shortly.  just want to document the change.  then i'll start on the error message stuff
19:58:04anderseecool
19:58:18anderseeLooks like we'll be good to go for a release tomorrow then
19:58:43mjn3the struct msqid_ds as defined seems to be in line with the kernel's struct msqid64_ds.  not sure though.  you'll need to check out the archs and see if there are any complications
19:58:58anderseek
19:59:08anderseeIs that part checked in yet?
19:59:28mjn3no.. i just replaced the struct def in common/bits/msq.h with:
19:59:32mjn3struct msqid_ds {
19:59:32mjn3struct ipc_perm msg_perm;
19:59:32mjn3struct msg *msg_first;/* first message on queue,unused  */
19:59:32mjn3struct msg *msg_last;/* last message in queue,unused */
19:59:33mjn3long msg_stime;/* last msgsnd time */
19:59:33mjn3long msg_rtime;/* last msgrcv time */
19:59:34mjn3long msg_ctime;/* last change time */
19:59:36mjn3unsigned long  msg_lcbytes;/* Reuse junk fields for 32 bit */
19:59:38mjn3unsigned long  msg_lqbytes;/* ditto */
19:59:40mjn3unsigned short msg_cbytes;/* current number of bytes on queue */
19:59:42mjn3unsigned short msg_qnum;/* number of messages in queue */
19:59:44mjn3unsigned short msg_qbytes;/* max number of bytes on queue */
19:59:46mjn3unsigned short msg_lspid;/* pid of last msgsnd */
19:59:48mjn3unsigned short msg_lrpid;/* last receive pid */
19:59:50mjn3};
19:59:52mjn3which is a "type-expanded" version of the i386 def
20:00:28anderseeI bet you every arch has some perverse variation on that struct.  Would be in charactor...
20:00:33anderseelooking
20:00:53mjn3from include/linux/msg.h (listed as obsolete for libc5 compiles)
20:02:05mjn3i'm sure they're all different...  but once this is fixed and i check in the stdio fix, perl passes all non-skipped tests.
20:07:04anderseemjn3:  You know, you can actually leave that struct _exactly_ as defined in the kernel and then be sure that you include bits/types.h
20:07:20anderseeThat will take care of any arch-dependent differences
20:07:42anderseeAnd will leave the kernel types intact
20:08:49mjn3it was just a quick test to make sure things worked.  i figured you'd know how you wanted to handle it.  ;-)
20:09:07mjn3all the python 2.2.1 tests still pass as well.
20:10:47anderseemjn3: ok.  I'll check that in now then.
20:14:13aaronlgah
20:14:15aaronlwhat ac kernel is somewhat stable?
20:14:32aaronl2.4.19-pre5-ac3 has been dying on me every few weeks
20:14:43aaronlsome process will eat up too much ram, and it gets stuck in an infinite loop in the OOM killer
20:16:16anderseemjn3: ok, the bits/msq.h change is in
20:16:50anderseeSo once we have your fclose changes in, we should be good to go.
20:17:06mjn3just the error stuff to do
20:17:10anderseeaaronl: I currently run 2.4.20-pre4-erik
20:17:29aaronlhehe
20:17:34anderseeoh yes.  The strerr problem.  
20:17:37aaronli thought you ran the AC patches too
20:17:53mjn3i'm thinking that it still might be worth setting the cookie ptr to NULL we're freeing the stream...
20:18:11anderseeaaronl: I bounce back and forth.  Not on -ac today as the IDE changes are not ready IMHO
20:18:51mjn3if you fclose a FILE * and it gets free'd and you try to reuse it, you deserve a segfault.
20:21:04anderseemjn3: indeed
20:21:37anderseemjn3: early warnings for bugs is much better than false security...
20:22:39mjn3let me test what glibc does...
20:22:49anderseemjn3: I think we should go ahead and kill HAS_LONG_LONG now as well
20:29:25mjn3andersee: ok.  would you believe that with glibc i can fopen a file for writing, fclose it, fprint to it, and not get an error until i fflush?  that's crazy
20:42:53anderseemjn3: thats nuts
20:45:12mjn3just did a cvs up and am rebuilding to test...
20:48:18mjn3unfortunately, i need to configure perl by hand.  :-(  and then partway through the build, it stops and i have to tweak a generated file and resume the build
20:59:00anderseecommitted to cvs.  HAS_LONG_LONG is no more.
21:00:06mjn3cool.  running perl 5.8 and python 2.2.1 tests...
21:05:46mjn3andersee: just committed the stdio mod.  perl and python both test clean.
21:07:21mjn3andersee: didn't think about it, but i'll have to put some of the scanf stuff you deleted back in to support bcc.  it doesn't have long long, but i use different headers that don't define LLONG_MAX and i'll test against that
21:07:48mjn3oh well, i need to go start supper...
21:09:34anderseek
21:09:40anderseecatch you later then

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net! Modified by Tim Riker to work with infobot logs, split per channel and by date, etc.