From: Leslie P. P. <sk...@vi...> - 2009-10-01 17:49:28
Attachments:
run-program-input-t.diff
|
Further amended the test case. Anyone willing to check and commit this fix? Leslie -- http://www.linkedin.com/in/polzer |
From: Attila L. <att...@gm...> - 2009-10-01 19:31:42
|
> Anyone willing to check and commit this fix? is this patch fixing this bug by any chance? https://bugs.launchpad.net/sbcl/+bug/435960 if so, we are +1 on the wishlist for the commit... -- attila |
From: Leslie P. P. <sk...@vi...> - 2009-10-01 19:50:26
|
Attila Lendvai wrote: >> Anyone willing to check and commit this fix? > > is this patch fixing this bug by any chance? > > https://bugs.launchpad.net/sbcl/+bug/435960 > > if so, we are +1 on the wishlist for the commit... Looks like it. Works fine here with my patched SBCL, although I had to add :INPUT T :OUTPUT T to cede control of the terminal -- maybe the defaults were changed since 1.0.19.35. Try my patch and let us know whether it fixes your problem too. Leslie -- http://www.linkedin.com/in/polzer |
From: Attila L. <att...@gm...> - 2009-10-02 09:25:59
|
> Try my patch and let us know whether it fixes your > problem too. positive, it fixed my problem, thanks!. bug updated with details/links at: https://bugs.launchpad.net/sbcl/+bug/435960 -- attila |
From: Christophe R. <cs...@ca...> - 2009-10-25 13:58:25
|
"Leslie P. Polzer" <sk...@vi...> writes: > Further amended the test case. +(with-test (:name (:run-program :inherit-stdin)) + (assert + (let (stopped) + (flet ((status-hook (proc) + (ecase (sb-ext:process-status proc) Is this test case actually working for you? It isn't for me. The reason, I think, is that when you process-kill with sigterm, that causes a status change, which isn't one of the magic four signals and hence gives :signalled, not :stopped; then status-hook is called, giving an error. At least, that's my diagnosis. But since the reason I myself was reluctant to merge this was because I didn't understand it, I would like confirmation from wiser heads. If this test case as stands (which is in CVS HEAD, incidentally) runs for everyone else, maybe because everyone's hardware is much more spiffy than mine and only I am vulnerable to a race condition, then fine. (But it seems wrong to me.) + (:stopped (setf stopped t))))) + (let ((proc (sb-ext:run-program "ed" nil :search t :wait nil + :input t :output t + :status-hook #'status-hook))) + ;; Give the program a generous time to generate the SIGTTIN. + ;; If it hasn't done so after that time we can consider it + ;; to be working (i.e. waiting for input without generating SIGTTIN). + (sleep 0.5) + ;; either way we have to signal it to terminate + (process-kill proc sb-posix:sigterm) + (process-close proc) + (not stopped)))))) Best, Christophe |
From: Christophe R. <cs...@ca...> - 2009-10-25 16:41:32
|
Christophe Rhodes <cs...@ca...> writes: > "Leslie P. Polzer" <sk...@vi...> writes: > >> Further amended the test case. > > +(with-test (:name (:run-program :inherit-stdin)) > + (assert > + (let (stopped) > + (flet ((status-hook (proc) > + (ecase (sb-ext:process-status proc) > > Is this test case actually working for you? It isn't for me. The > reason, I think, is that when you process-kill with sigterm, that causes > a status change, which isn't one of the magic four signals and hence > gives :signalled, not :stopped; then status-hook is called, giving an > error. > > At least, that's my diagnosis. But since the reason I myself was > reluctant to merge this was because I didn't understand it, I would like > confirmation from wiser heads. If this test case as stands (which is in > CVS HEAD, incidentally) runs for everyone else, maybe because everyone's > hardware is much more spiffy than mine and only I am vulnerable to a > race condition, then fine. (But it seems wrong to me.) After some discussion with people who are awake at this point in the day on #lisp IRC, I convinced myself of two things: * it is a race condition: if the ed(1) process is terminated by the SIGTERM before the SIGCHLD handler in sbcl runs, then waitpid() fails and the process is deleted from *active-processes*, under which conditions the status-changed hook in the test is never run. My guess is that this happens commonly on multiprocessors; on my uniprocessor with non-threaded SBCL, the run-program test for inherited stdin failed apparently deterministically. * no-one much seems to be testing anything much during the freeze period. (I can't really believe that I'm the only one with this particular failure mode; also, the last-minute testing that I coerced from victims on IRC suggest that there are regressions or at least unexpected test failures on FreeBSD). Consequently, I have released sbcl-1.0.32. Go forth and destabilize. Cheers, Christophe |
From: Leslie P. P. <sk...@vi...> - 2009-10-26 09:06:35
|
Christophe Rhodes wrote: > * it is a race condition: if the ed(1) process is terminated by the > SIGTERM before the SIGCHLD handler in sbcl runs, then waitpid() fails > and the process is deleted from *active-processes*, under which > conditions the status-changed hook in the test is never run. My guess > is that this happens commonly on multiprocessors; on my uniprocessor > with non-threaded SBCL, the run-program test for inherited stdin > failed apparently deterministically. Indeed, I successfully ran the test case multiple times on two different quad cores but no uniprocessor machine. Thanks for spotting this problem. It's unfortunate that no one else seems to have tested or encountered this before. > * no-one much seems to be testing anything much during the freeze > period. I do, FWIW. Leslie -- http://www.linkedin.com/in/polzer |
From: Attila L. <att...@gm...> - 2009-10-26 10:25:51
|
>> * no-one much seems to be testing anything much during the freeze >> period. > > I do, FWIW. +1 i regularly compile sbcl and use HEAD (+ a few patches) for my daily work. -- attila |
From: Martin C. <cra...@co...> - 2009-10-26 15:38:13
|
Christophe Rhodes wrote on Sun, Oct 25, 2009 at 04:41:16PM +0000: > > * no-one much seems to be testing anything much during the freeze > period. (I can't really believe that I'm the only one with this > particular failure mode; also, the last-minute testing that I coerced > from victims on IRC suggest that there are regressions or at least > unexpected test failures on FreeBSD). I push it through an extensive set of regression tests (after application build). No CLOS, no threads, pretty much no streams, though. And yes, there is a huge hole around interactive use. In particular if SLIME breaks nobody will notice. I am not sure what to do here except using expect(1) (the TCL terminal emulator stuff) to do an automated test. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ |
From: Ram B. <ra...@gm...> - 2009-10-26 18:44:53
|
On Mon, Oct 26, 2009 at 8:37 AM, Martin Cracauer <cra...@co...> wrote: > Christophe Rhodes wrote on Sun, Oct 25, 2009 at 04:41:16PM +0000: >> >> * no-one much seems to be testing anything much during the freeze >> period. (I can't really believe that I'm the only one with this >> particular failure mode; also, the last-minute testing that I coerced >> from victims on IRC suggest that there are regressions or at least >> unexpected test failures on FreeBSD). > > I push it through an extensive set of regression tests (after > application build). No CLOS, no threads, pretty much no streams, > though. > > And yes, there is a huge hole around interactive use. In particular > if SLIME breaks nobody will notice. I am not sure what to do here > except using expect(1) (the TCL terminal emulator stuff) to do an > automated test. > It would also be possible to write some test code in emacs lisp itself. It would likely be easier than trying to use expect. If someone had a set of things to test I could take a crack at creating the tests. -Ram |
From: Tobias C. R. <tc...@fr...> - 2009-10-26 19:17:51
|
Ram Bhamidipaty <ra...@gm...> writes: > > And yes, there is a huge hole around interactive use. In particular > > if SLIME breaks nobody will notice. I am not sure what to do here > > except using expect(1) (the TCL terminal emulator stuff) to do an > > automated test. > > > > It would also be possible to write some test code in emacs lisp itself. > It would likely be easier than trying to use expect. If someone had a > set of things to test I could take a crack at creating the tests. Slime actually comes with a test suite which is also runnable from the command line. See `test.sh' in the slime checkout. -T. |
From: Christophe R. <cs...@ca...> - 2009-10-27 20:08:35
|
Attila Lendvai <att...@gm...> writes: >>> * no-one much seems to be testing anything much during the freeze >>> period. >> >> I do, FWIW. > > +1 > > i regularly compile sbcl and use HEAD (+ a few patches) for my daily work. Yes, sorry about my excessive grumpiness; I was grumpy. I do realise that people do test things, and it's not easy to cover all cases; I was just unpleasantly surprised on release day. Relatedly, if anyone has the energy to update the sbcl website to reflect the new release, that would be much appreciated. Cheers, Christophe |
From: Christophe R. <cs...@ca...> - 2009-10-29 15:00:53
|
Christophe Rhodes <cs...@ca...> writes: > Relatedly, if anyone has the energy to update the sbcl website to > reflect the new release, that would be much appreciated. I think I've now done this; please notify the list if there's something wrong. Best, Christophe |