[00:40:29] --- Russ has left: Disconnected [00:47:46] --- kaj has left [00:47:48] --- kaj has become available [01:08:07] --- jaltman has left: Disconnected [01:08:16] --- jaltman has become available [02:18:28] --- jaltman has left: Disconnected [02:48:12] --- jaltman has become available [02:58:11] --- jaltman has left: Disconnected [03:00:09] --- jaltman has become available [03:01:21] --- kaj has left [03:01:38] --- kaj has become available [03:14:29] --- jaltman has left: Replaced by new connection [03:14:30] --- jaltman has become available [03:26:19] --- jaltman has left: Disconnected [03:27:09] --- jaltman has become available [03:42:10] --- jaltman has left: Disconnected [03:42:31] --- jaltman has become available [04:36:46] If there are any bored gatekeepers around, could someone review & push 2120, so the tree builds again ... [04:53:29] --- Jeffrey Altman has left: Replaced by new connection [04:53:31] --- Jeffrey Altman has become available [04:55:05] --- jaltman has left: Replaced by new connection [04:55:06] --- jaltman has become available [05:05:56] --- jaltman has left: Replaced by new connection [05:05:57] --- jaltman has become available [05:08:47] --- dwbotsch has left [05:09:06] --- cudave has become available [05:35:57] --- jaltman has left: Disconnected [05:36:06] --- jaltman has become available [06:12:20] --- matt has become available [06:40:28] --- reuteras has left [07:05:33] --- haba has become available [07:19:21] --- deason has become available [08:33:27] --- haba has left [10:02:34] --- mattjsm has become available [10:49:34] --- Russ has become available [11:49:38] --- Kevin Sumner has left [11:49:44] --- Kevin Sumner has become available [12:00:03] mattjsm: a look at /usr/src/sys/fs/smbfs/smbfs_vfsops.c (etc) suggests that the starting point is to replace these uses of simple_lock with mutex_enter, and so on. [12:01:48] That's the vnode interlock--whether the use we are making of it is legit...we'll learn more about that soon [12:02:25] Clearly some bundled fses do, fwiw. [12:10:10] VNODE(9) still thinks these are simplelocks. have a nice day. [12:10:35] that and VNSUBR(9) are pages you should read [12:13:23] actually, this usage is valid, as far is it goes (update v_usecount). [12:14:42] --- Kevin Sumner has left [12:15:13] --- Kevin Sumner has become available [12:20:35] Which usage is valid? The current one? [12:21:47] the one at osi_vnodeops.c:260 [12:24:12] k. I just figure that there's a var missing somewhere to appease the lock_date requirement [12:24:13] the caller will take the interlock to update v_usecount, v_holdcount, and flags, and vn_lock in most other cases, see the vnode manpage [12:25:50] --- mmeffie has left [12:26:38] --- mmeffie has become available [12:30:52] but the problem the compiler sees is simpler--netbsd has changed the types of the vnode lock members in 50 [12:31:24] we have to follow suit [12:35:15] I can see that for the rest of the errors spit out, sure. I'm still poking through the manpages to decipher the issues with lock_data tho. :) [12:36:36] is that being referenced by simple_lock(...)? [12:37:23] #define SIMPLELOCK_INITIALIZER { .lock_data = __SIMPLELOCK_UNLOCKED } [12:37:31] from simplelock.h [12:37:43] it's going to go away when we stop using simple_lock [12:38:06] LOCK(9): [12:38:18] "These interfaces have been obsoleted and removed from the system. Please see the condvar(9), mutex(9), and rwlock(9) manual pages for information on kernel synchronisation primitives. " [12:41:52] could we just call the built-in mutex_lock on the interlock, then? [12:42:55] right, call mutex_enter on it. as cross check, we note that the bundled filesystems do just this [12:58:07] --- mattjsm has left [13:04:58] I wonder how sorry this set of static analysis results is going to make me ... [13:05:17] depends what you analyzed :) [13:05:32] OpenAFS. git master. [13:05:42] all of it? some of it? [13:06:02] All of it that gets built with a standard compiler - so not the kernel module. [13:06:11] ok. "a lot" [13:06:19] lwp ftw [13:06:26] Yeah. Going to ignore that. [13:14:51] Even just clang finds some bugs that gcc misses ... [13:16:38] I have a report of someone who's getting file server crashes since updating to the 1.4.12.1+dfsg-1 packages in Debian (from 1.4.12+dfsg-5). I suspect nothing in the .1 release, since that was all client fixes, but possibly [c29ac4fe] viced host UUID and address hashing corrections which I pulled up from the stable repository. [13:16:43] He's going to submit a bug report to openafs-bugs. [13:17:26] The last message he gets in FileLog before the crash is Fri Jun 11 09:24:15 2010 CB: ProbeUuid for (<84>^?:-1433838912) failed 45946 [13:17:33] Which looks like some sort of internal state corruption. [13:18:16] amd64, in case it matters. [13:18:59] back in about 30 [13:19:01] i'd have guessed we got AFS_PTR_FMT wrong, myself [13:19:04] WTF is that patch doing defining AFs_PTR_FMT [13:19:27] --- mattjsm has become available [13:19:44] If it's doing that, and we don't PTR_FMT support in our afs_snprintf ... [13:19:54] in fact i'd put money on it being that and not any sort of [13:19:56] yeah [13:20:20] Oh, okay. That's a much simpler problem. [13:20:24] indeed. [13:20:32] So afs_printf is then segfaulting? [13:20:39] Since he does get that output. [13:20:43] So that call at least succeeds. [13:21:50] Really gone now -- back in a few. [13:22:01] We certainly haven't pulled any of the snprintf fixes up to head. [13:22:07] up to 1.4, even. [13:22:43] * - At present, the 'p' specifier for printing pointers is not * implemented, because it is inherently non-portable and thus * can be implemented correctly only by the compiler's run-time * library. [13:23:33] Yes, but it is implemented on master. It looks like whoever did that pullup just decided to define AFS_PTR_FMT in the .c file, and hope for the best ... [13:23:58] yeah, I know; I don't agree with the comment, but it certainly implies it's not in 1.4 [13:24:44] Oh, It's definitely not in master. Neither Derrick's commit that implemented it, nor Jeff's commit which ripped out our entire sorry snprintf implementation and replaced it with Love's are in 1.4. [13:24:52] --- Kevin Sumner has left [13:24:59] --- abo has left [13:25:02] 1.4 does 0x%x, for pointers, IIRC. [13:25:15] --- Kevin Sumner has become available [13:25:25] --- abo has become available [13:42:59] --- mattjsm has left [13:48:18] Does ViceLog use afs_snprintf? [13:48:26] The system snprintf on Debian certainly does support %p. [13:48:40] Yes. [13:51:19] ViceLog is FSLog is vFSLog which calls afs_vsnprintf [13:51:39] (in 1.4, it had to, because 1.4 used a number of completely non-standard printf features) [13:53:29] Aha. So %p isn't supported, so we segfault the first time that offsetting all of our prompts by one causes us to, say, dereference an integer as a pointer. [13:53:42] I suspect so, yes. [13:54:26] Should we back out that patch completely or just define it to 0x%x? [13:55:01] Well, we've not shipped with that code yet :) [13:55:41] I think the correct thing to do is to just replace AFS_PTR_FMT with 0x%x - which will give us the same compiler warnings that litter the rest of the 1.4 tree. [13:56:32] (I'd rather not define AFS_PTR_FMT at all in 1.4.x, as it makes it easier to do pull ups without understanding the consequences. If we can encourage the people doing the pullup to think, and hopefully reviewers to notice, maybe we can avoid this happening again) [14:18:46] wiki is lagging... [14:19:10] Someone's probably trying to crawl it again ... [14:19:37] I think Derrick is the only one with the necessary bits to kick it back to life. [14:20:59] not a problem [15:10:41] Not as bad as I expected - clang-analyzer finds 1417 potential bugs [15:45:01] --- deason has left [16:26:08] I was thinking a bit on how to test the gets functions in StrSafe.h. Would it be reasonable to write some kind of echo/pipe program that uses the functions to read a line from stdin and then writes that line to stdout, then checking various in-/outputs with a shell script? [16:28:26] you could certainly do that, but it likely isn't sufficient for all of the things you want to test. [16:28:57] Do you have any suggestions for other ways to test? [16:29:01] I would hand craft input that tests the success and failure conditions [16:29:53] I think the program would read until EOF and write a line for each time gets is called, with a possibility to specify the capacity of the reading buffer. [16:30:17] Yeah, input files that will test the various conditions that could occur. [16:32:23] Perhaps some kind of syntax to signal what the return code was for each call? [16:33:06] Jeffrey: By the way, should the error codes have the same values as they have in the Microsoft implementation of the library? I don't think they mention the actual values in the documentation. [16:34:25] I think the symbols for the error values should be the same as in the documentation. I do not believe the error codes need to be the same. [16:35:24] That's the current state. It wouldn't be hard to fix the values if that would be needed at a later stage. [16:36:03] exactly. I just don't want to have you look at header files to find out what the Microsoft values are because you are supposed to be producing a clean room version [16:36:43] The values for the flags used in the extended functions are documented though, so those can have the same values. [16:37:11] generally, I would not do "read until EOF"; I'd run the program separately for each and every test. That way you don't run into a situation where a bug triggered by one test also breaks later, supposedly independent tets. [16:38:05] But you still want to make sure that the line breaks and lines that are too long will be handled correctly (nothing is removed from stdin if it isn't read to the output). [16:38:17] The tests would still be run with several calls to that function [16:38:41] Just that one test might be to make sure "foo\nbar" will be read properly. [16:40:59] Oh, I see. Yes, I suppose you'd want the program to attempt to read multiple lines, so you can verify that that works when expected and not otherwise. However, consider a test program that calls gets repeatedly until EOF, and each time prints to stdout the line it read. Now, how do you tell the difference between "foo\nbar" being read as "foo\n" followed by "bar" as opposed to being read as "foo\nbar" (i.e. gets fails to recognize the newline) [16:42:08] It might wrap the input it reads with some own text: "Line 1: "foo" - S_OK\nLine 2: "bar" - STRSAFE_E_END_OF_FILE" [16:42:36] Hm, that sounds workable [16:44:22] One problem might be that line breaks might be encoded differently on different platforms. [16:46:57] I would craft two sets of inputs to the test program. One set that defines the test including the functions to be call and the expected sets of results. The other is the input file that is processed by the gets() call. [16:47:15] not all of the tests will have separate external input files. [16:47:18] I'm not sure what the semantics are suppsoed to be. Is it supposed to handle arbitrary types of newlines on input, or just the "standard" newline for the current platform, or...? As for the output, I think you can define your program to use whatever newlines you want. You could just separate lines with "~" for that matter [16:51:01] Newline is "\n" for StringCbGets and StringCbGetsEx. The conversion from "\r\n" to "\n" is handled by the CRT on Windows. [16:51:52] How will the tests be run on Windows, in Cygwin? [16:52:10] that I haven't figured out yet :-) [16:52:33] <_cclausen> I would prefer non-cygwin [16:52:55] so would I but we might not have a choice [16:53:13] runtests uses pipe() and exec() at the moment. I'm happy to take Windows modifications if we can figure out a good way to handle it. [16:53:15] For the gets functions it would be hard to test without resorting to some platform dependance [16:54:40] Either using a shell script or rerouting stdin. [16:55:07] rerouting stdin can be done on windows [16:55:53] I guess that might require separate test files for running the tests on Windows. [16:57:11] But it would be possible to write a C program that does the rerouting and then calls the functions instead of using a shell script that calls the binary. [16:57:20] sure [16:58:20] I don't think separate input files per test are necessarily a bad thing. [16:59:13] Of course, yuo could also emit a temporary input file as part of setting up to run the test. [16:59:28] How about this: I use the shell script from the C TAP Harness for now. That would then be converted to a C program with stdin/stdout rerouting for Windows testing of the gets functions at a later time? [17:00:03] I don't think you should block on testing windows at the present time [17:00:39] by the middle of July I will have time to do some Windows specific work with you. [17:00:54] Could Cygwin be enough for testing at the moment? [17:00:56] its hard at the moment with the things going on in my personal life [17:01:03] cygwin would be fine for now [17:01:56] I could try setting up some development tools in Windows to run the Windows tests myself. [17:02:00] we require cygwin for building the documentation so I don't really care if there is a dependency on it for OpenAFS to perform testing of StrSafe. However, StrSafe is independent of OpenAFS and has to be able to be tested on its own [17:02:40] Of course, the reason for performing the tests on Windows is to test the Microsoft StrSafe implementation to ensure that it is compliant with their docs [17:03:33] Is the Microsoft implementation available through Cygwin? [17:04:28] Also, should I run tests against their implementation or could that be a problem later? [17:04:57] testing their implementation is fine but I would prefer it be done by someone other than you [17:07:08] Do the pipe() and exec() calls in runtests make it incompatible with Windows or does it just make the tests run slower? [17:07:25] there is no pipe() in the Windows CRT [17:07:31] and there is no fork() [17:07:54] cygwin has an implementation. [17:09:37] And the StrSafe.h functions are the implementation by Microsoft if I just include the header and compile in Cygwin? [17:10:15] Or do they supply their own libraries with Cygwin/MinGW? [17:10:21] cygwin tools are gcc [17:10:44] we would need to build with the microsoft tools to build with strsafe.h [17:11:40] --- mmeffie has left [17:12:17] Right, I'll try to look into rerouting stdin/stdout next week. [17:13:04] --- Kevin Sumner has left [17:13:05] --- mmeffie has become available [17:13:26] --- Kevin Sumner has become available [17:13:41] Do I need to use MSVC for building? [17:19:16] --- matt has left [17:19:43] Another thing that might be a problem: I'm not sure if I'm allowed to use my Windows installation for doing this, since it's a student version that I got through MSDN Academic Alliance ("You may not use MSDNAA software for any for-profit software development") [17:20:14] That same requirement would be put on the MSVC version that I have available as well. [17:20:54] I think that GSoC might qualify as being for-profit, but I'm not entirely sure. [17:29:17] While I think you are technically correct, you are selling code to Google, the license you are using permits use of it without paying for it. I think the spirit of the license is being met. [17:29:58] you can download the WDK from connect.microsoft.com for free and it contains the necessary headers, libs and compilers [17:36:38] Okay, I'll take a look at that. [17:38:10] One problem might be that I had a computer failure this morning. Hopefully it's nothing that can't be fixed and I can get it up and running without replacing hardware. At the moment I'm using my laptop that doesn't have Windows on it and it might be a bit slow for running it in a virtual machine. [17:39:04] if there is a serious problem I can give you access to a windows build machine provided that you have a remote desktop client that supports TLS protected sessions [17:40:10] It shouldn't be much of a problem. If I can't get my desktop up and running, I'll get another copy of Windows from MSDN AA and install it on my laptop. [17:50:49] --- Russ has left: Disconnected [18:11:20] --- Russ has become available [20:17:34] (stark) Hm, the fbsd guys have been claiming that they have a clang that builds the kernel. Maybe I should figure out how to use it and run it over the kernel parts ... [20:53:26] --- jaltman has left: Replaced by new connection [20:53:27] --- jaltman has become available [22:51:25] --- Russ has left: Replaced by new connection [22:51:25] --- Russ has become available [23:29:38] --- Russ has left: Disconnected