14:09:20 | tzanger | morning |
14:11:03 | mjn3 | morning |
19:41:28 | mjn3 | andersee: hey. testing a fix for the perl msg queue stuff. found and fixed the 2 exit failures as well. grr... |
19:42:34 | mjn3 | andersee: 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:28 | mjn3 | andersee: 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:54 | mjn3 | andersee: 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:48 | mjn3 | andersee: 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:01 | andersee | cool. |
19:55:52 | andersee | So what did you change for the flopencookie stuff? Just retuen EBADF after files are closes? |
19:57:14 | mjn3 | no. 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:44 | mjn3 | i'll get that checked in shortly. just want to document the change. then i'll start on the error message stuff |
19:58:04 | andersee | cool |
19:58:18 | andersee | Looks like we'll be good to go for a release tomorrow then |
19:58:43 | mjn3 | the 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:58 | andersee | k |
19:59:08 | andersee | Is that part checked in yet? |
19:59:28 | mjn3 | no.. i just replaced the struct def in common/bits/msq.h with: |
19:59:32 | mjn3 | struct msqid_ds { |
19:59:32 | mjn3 | struct ipc_perm msg_perm; |
19:59:32 | mjn3 | struct msg *msg_first;/* first message on queue,unused */ |
19:59:32 | mjn3 | struct msg *msg_last;/* last message in queue,unused */ |
19:59:33 | mjn3 | long msg_stime;/* last msgsnd time */ |
19:59:33 | mjn3 | long msg_rtime;/* last msgrcv time */ |
19:59:34 | mjn3 | long msg_ctime;/* last change time */ |
19:59:36 | mjn3 | unsigned long msg_lcbytes;/* Reuse junk fields for 32 bit */ |
19:59:38 | mjn3 | unsigned long msg_lqbytes;/* ditto */ |
19:59:40 | mjn3 | unsigned short msg_cbytes;/* current number of bytes on queue */ |
19:59:42 | mjn3 | unsigned short msg_qnum;/* number of messages in queue */ |
19:59:44 | mjn3 | unsigned short msg_qbytes;/* max number of bytes on queue */ |
19:59:46 | mjn3 | unsigned short msg_lspid;/* pid of last msgsnd */ |
19:59:48 | mjn3 | unsigned short msg_lrpid;/* last receive pid */ |
19:59:50 | mjn3 | }; |
19:59:52 | mjn3 | which is a "type-expanded" version of the i386 def |
20:00:28 | andersee | I bet you every arch has some perverse variation on that struct. Would be in charactor... |
20:00:33 | andersee | looking |
20:00:53 | mjn3 | from include/linux/msg.h (listed as obsolete for libc5 compiles) |
20:02:05 | mjn3 | i'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:04 | andersee | mjn3: 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:20 | andersee | That will take care of any arch-dependent differences |
20:07:42 | andersee | And will leave the kernel types intact |
20:08:49 | mjn3 | it was just a quick test to make sure things worked. i figured you'd know how you wanted to handle it. ;-) |
20:09:07 | mjn3 | all the python 2.2.1 tests still pass as well. |
20:10:47 | andersee | mjn3: ok. I'll check that in now then. |
20:14:13 | aaronl | gah |
20:14:15 | aaronl | what ac kernel is somewhat stable? |
20:14:32 | aaronl | 2.4.19-pre5-ac3 has been dying on me every few weeks |
20:14:43 | aaronl | some process will eat up too much ram, and it gets stuck in an infinite loop in the OOM killer |
20:16:16 | andersee | mjn3: ok, the bits/msq.h change is in |
20:16:50 | andersee | So once we have your fclose changes in, we should be good to go. |
20:17:06 | mjn3 | just the error stuff to do |
20:17:10 | andersee | aaronl: I currently run 2.4.20-pre4-erik |
20:17:29 | aaronl | hehe |
20:17:34 | andersee | oh yes. The strerr problem. |
20:17:37 | aaronl | i thought you ran the AC patches too |
20:17:53 | mjn3 | i'm thinking that it still might be worth setting the cookie ptr to NULL we're freeing the stream... |
20:18:11 | andersee | aaronl: I bounce back and forth. Not on -ac today as the IDE changes are not ready IMHO |
20:18:51 | mjn3 | if you fclose a FILE * and it gets free'd and you try to reuse it, you deserve a segfault. |
20:21:04 | andersee | mjn3: indeed |
20:21:37 | andersee | mjn3: early warnings for bugs is much better than false security... |
20:22:39 | mjn3 | let me test what glibc does... |
20:22:49 | andersee | mjn3: I think we should go ahead and kill HAS_LONG_LONG now as well |
20:29:25 | mjn3 | andersee: 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:53 | andersee | mjn3: thats nuts |
20:45:12 | mjn3 | just did a cvs up and am rebuilding to test... |
20:48:18 | mjn3 | unfortunately, 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:00 | andersee | committed to cvs. HAS_LONG_LONG is no more. |
21:00:06 | mjn3 | cool. running perl 5.8 and python 2.2.1 tests... |
21:05:46 | mjn3 | andersee: just committed the stdio mod. perl and python both test clean. |
21:07:21 | mjn3 | andersee: 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:48 | mjn3 | oh well, i need to go start supper... |
21:09:34 | andersee | k |
21:09:40 | andersee | catch you later then |