00:22:05 Phoodus [~foo@68.107.217.139] has joined #sbcl 00:22:43 Is there any way to set --dynamic-space-size from lisp itself in some early startup phase of sbcl? 00:23:48 by the time you can run lisp code then there isn't much startup left to do 01:00:07 -!- homie [~levgue@xdsl-78-35-130-40.netcologne.de] has quit [Read error: Operation timed out] 01:00:52 homie` [~levgue@xdsl-78-35-155-90.netcologne.de] has joined #sbcl 01:11:08 is :save-runtime-options under save-lisp-and-die just held as strings inside the image? I presume I could hack into those before cycling the image to re-set the options 02:03:23 no, there's a C struct inside the image 02:59:26 attila_lendvai [~attila_le@87.247.15.185] has joined #sbcl 02:59:26 -!- attila_lendvai [~attila_le@87.247.15.185] has quit [Changing host] 02:59:26 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:45:33 -!- akovalenko [~anton@95.72.168.38] has quit [Read error: Connection reset by peer] 04:45:54 akovalenko [~anton@95.72.175.8] has joined #sbcl 05:03:39 -!- beslyrus [~Brucio-12@adsl-99-35-53-209.dsl.pltn13.sbcglobal.net] has quit [Remote host closed the connection] 05:27:38 -!- homie` [~levgue@xdsl-78-35-155-90.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:32:07 akovalen` [~anton@95.72.175.8] has joined #sbcl 05:32:40 -!- akovalenko [~anton@95.72.175.8] has quit [Ping timeout: 240 seconds] 05:44:32 m801 [~user@ip68-7-188-238.sd.sd.cox.net] has joined #sbcl 05:44:49 -!- m801 [~user@ip68-7-188-238.sd.sd.cox.net] has quit [Client Quit] 05:46:19 m801 [~user@ip68-7-188-238.sd.sd.cox.net] has joined #sbcl 05:51:09 -!- m801 [~user@ip68-7-188-238.sd.sd.cox.net] has left #sbcl 06:05:30 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 260 seconds] 07:48:45 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 07:49:05 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 07:49:17 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 08:37:30 Kryztof [~user@81.174.155.115] has joined #sbcl 08:37:30 -!- ChanServ has set mode +o Kryztof 08:53:10 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:47:29 hlavaty [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 10:26:10 |3b|` [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 10:26:49 -!- |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has quit [Read error: Connection reset by peer] 10:27:14 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 10:27:14 -!- ChanServ has set mode +o nikodemus 10:33:41 -!- akovalen` is now known as akovalenko 10:44:03 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Disconnected by services] 10:44:04 nikodemus_ [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 10:44:36 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 10:44:36 -!- ChanServ has set mode +o nikodemus 10:48:04 morning 10:48:09 well, noon 11:17:20 Hey nikodemus. 11:18:24 hi 11:18:28 interesting post! 11:18:30 Is there a lot of overlap between my tool and yours? (in terms of features and/or scope) 11:18:49 probably not much 11:19:23 mine started life as using sbcl's call-with-timing, but current version just uses get-internal-real-time and get-internal-run-time for portability 11:19:40 that's good. I feel less bad about not having released this ages ago. 11:19:47 :-) 11:19:47 but i think they could probably be combined to good effect 11:20:22 Yeah, I used this to generate some lousy plots with gnuplot. I want nice plots like yours. :-) 11:20:36 Well, actually, I don't have a good use for this anymore. 11:20:47 Maybe some day in the future. 11:21:02 cl-who + parenscript-classic + google visualization api makes for an easy life :) 11:21:46 nikodemus pasted "chart generation" at http://paste.lisp.org/display/125908 11:22:59 nikodemus: Doing any publicly observable stuff with that trio? 11:23:30 antoszka: see his latest blog post. :-) 11:24:30 ok 11:33:29 -!- drdo [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Ping timeout: 276 seconds] 12:39:13 -!- churib [~churib@95.156.194.105] has left #sbcl 13:13:19 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 244 seconds] 13:14:14 attila_lendvai [~attila_le@87.247.49.245] has joined #sbcl 13:14:14 -!- attila_lendvai [~attila_le@87.247.49.245] has quit [Changing host] 13:14:14 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:28:18 nikodemus: another thing I have is a first stab at a benchmark suite for CL à la Java's Dacapo. Something with real apps as opposed to micro-benchmarks. 13:33:55 luis: maybe we should collaborate 13:35:30 antgreen [user@nat/redhat/x-cowmnnnoexfxlvhw] has joined #sbcl 13:41:38 luis: my interest is mainly microbenchmark oriented, because they make tracking regressions much easier -- and also allow comparison of slow and fast paths like in my post 14:29:04 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 14:29:15 G'morning all. 14:29:34 hello 14:29:36 nikodemus: I have that review branch building now. 14:29:42 excellent 14:30:38 how long is the build expected to take? 14:31:56 Not sure, I'm figuring 60-90 minutes, plus time to notice, plus time to run the test suite. 14:32:29 I'll also use the build report, if it doesn't fail somewhere along the line, to calibrate my sense of how long that machine takes to do a build. 14:33:37 It's somewhat unfortunate that it's not a slammable change, really. 14:33:55 Oh, and for some reason cloning off of github doesn't propagate tags? 14:46:13 never noticed that 14:46:23 re. patch. aside from possibly putting in a couple of barriers not strictly needed, it looks ok to you? 14:48:48 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: Leaving] 14:49:36 Pretty much okay, if it works. 14:49:54 ISTR that BARRIER also introduces an implicit PROGN, FWIW. 14:50:49 Heh. I checked the build progress, and it's on target-thread. 14:52:01 nyef: actually, i was just going to mention that while (barrier (:write) (code-that-writes)) is convenient, it's too bad the order doesn't work for :read 14:52:21 but what would probably be too dwim 14:52:41 Actually, can we FLET keywords? 14:53:03 we can 14:53:32 wait, actually... 14:53:45 What if we changed the semantics of BARRIER to FLET the various barrier kind keywords...? 14:54:05 is (code-that-reads) (barrier (:read)) (code-that-uses-stuff-that-was-read) actually TRT? 14:54:17 No, it's not. 14:54:28 You read-barrier, -then- read. 14:54:39 ok, that's what i thought 14:54:46 just wanted to make sure 14:54:53 But you write, then write-barrier. 14:55:12 nyef: i would be surprised if doing that broke any code 14:55:33 Hrm. FLET isn't quite the semantic we'd want, as we'd prefer the barrier to not provide the return value if it's the last form... 14:55:43 right 14:55:55 so you need to walk the body 14:56:12 And that's just not on. 14:56:39 The other possibility is if they act as VALUES as well. 14:56:44 what if you say that (:foo) forms can appear in body, but not as subforms? 14:57:05 That could work as well. Like TAGBODY, right? 14:57:13 yeah 14:58:05 Still have to be wrapped in parens for backwards compatibility, but would be workable. 14:58:27 sounds good to me 14:58:51 Or we could just leave things as-is for now. 15:01:16 It's really too bad we don't have threaded alpha. Or any real alpha boxes to work with. Finding and fixing all the places that need a data-dependency barrier would be interesting. 15:03:36 to be honest, it also makes me wonder if using alpha as our notional memory model is ideal 15:04:08 the linux kernel prior art is a huge boon, though 15:05:01 The prior art thing is huge. 15:05:29 Isn't there an opencores alpha project, anyway? 15:08:31 48 minute build-time on an unloaded system, btw. 15:09:37 Looks like it might have locked up fairly quickly in testing, too. 15:09:53 I'll give it a few more minutes. 15:10:24 -!- antgreen [user@nat/redhat/x-cowmnnnoexfxlvhw] has quit [Remote host closed the connection] 15:18:54 where is it sitting? 15:19:53 nyef pasted "deadlock backtrace" at http://paste.lisp.org/display/125911 15:20:12 It's sitting right about there. 15:20:35 Still in symbol-value-in-thread.3, too 15:21:02 so it's failing to stop T1? 15:21:22 can you get a lisp backtrace for that thread? 15:23:16 Umm... maybe. "thread apply 1 call lisp_backtrace()"? 15:23:44 Then again, we know where it's stopped, don't we? 15:23:48 It's in join-thread. 15:24:13 Simply because that's what it does after kicking off T3. 15:24:15 possibly. i tend to use: thread 1; call backtrace_from_fp($rbp, 100) 15:24:26 obviously with a different register there 15:24:27 I see no $rbp here. 15:24:45 ISTR that backtrace_from_fp() is an x86oidism. 15:24:50 ok 15:25:31 Ahh... Okay, lisp_backtrace() takes nframes. I'll give it a shot. 15:27:11 nyef annotated #125911 "giving up on lisp_backtrace... but interesting signal games occur" at http://paste.lisp.org/display/125911#1 15:27:36 SIGUSR2 is stop_for_gc, isn't it? 15:29:09 yeah 15:29:45 if you can replicate the hang, does T1 have SIGUSR2 blocked? 15:30:05 if not, does the test-case just manage to fill the signal queue? 15:30:31 How do I find out if it has SIGUSR2 blocked? 15:31:11 give me a minute... 15:32:05 homie [~levgue@xdsl-78-35-182-134.netcologne.de] has joined #sbcl 15:33:41 I'll kill out the test run and restart it. It should block fairly quickly. 15:33:42 aha. call describe_thread_state 15:33:50 Oh. 15:34:05 Is that likely to work even with the errors from trying to call lisp_backtrace()? 15:34:23 i would hope so 15:34:44 but i can paste you the interactions to get it manually as well 15:35:25 Hum. gdb can't find describe_thread_state(). 15:38:35 call malloc(sizeof(sigset_t)) 15:38:35 call get_current_sigmask($1) 15:38:35 call sigismember($1, 10) 15:38:59 except grep -r SIGUSR /usr/include to check what SIGUSR1 is there 15:39:03 it's 10 here, but... 15:40:09 10 here too 15:43:36 SIGUSR1 or SIGUSR2? 15:43:51 Actually, hang on. 15:43:53 10 or 12 ? 15:44:04 The signal was /delivered/ the first time I used call. 15:44:06 #define SIG_STOP_FOR_GC (SIGUSR2) 15:44:14 right, SIGUSR2 -- my bad 15:44:50 when you did call malloc? 15:44:55 huh 15:46:30 that is, did it get delivered when you did "call malloc(...)" or are you referring to the earlier paste? 15:53:05 Earlier paste. 15:53:28 I quit out and retried the test. It deadlocked again, but... 15:53:42 When I attached, two threads were stopped for GC and one was running GC. 15:54:05 so not deadlocked? 15:54:26 So, a deadlock that doesn't affect GC or the noise thread. 15:54:58 hum 15:55:20 hey, the test-case itself is missing barriers... 15:55:39 it uses a closed-over variable to tell the allocator-thread to stop 15:56:02 Both active threads are in nanosleep. 15:56:10 Yeah, not worried about that one. 15:56:30 It's not like the usual interrupt games won't force it eventually. 15:57:06 so the other one is in JOIN-THREAD and the other one in WAIT-ON-SEMAPHORE -- probably 15:57:18 Probably, yes. 15:58:13 If you want a test that is clearly broken on PPC, have a look at threads.impure.lisp / binding-stack-gc-safety. It's so completely bad that it's funny. 15:58:47 But it's not quite relevant to the problem at hand. 15:59:24 one thing you could do would be to add one more thread that prints all the guts of the semaphore every 10s or so, and similarly for thread-result-lock and -interruptions-lock of the noise-thread 15:59:53 (seems easier than trying to dig after those things from gdb...) 16:00:35 I was wondering what would happen if I delivered a SIGINT to the parent thread. 16:00:51 only one way to find out! 16:00:52 tyson2 [~Ian@76-10-173-74.dsl.teksavvy.com] has joined #sbcl 16:01:29 Well said. 16:01:49 nyef: do you know how different libc and pthreads are between ppc and x86oid linuxes? 16:02:40 i'm wondering if some of the trouble is related to our abuse of pthread functions inside signal handlers, which x86oid linuxes seems fairly blase about, but which isn't posixly correct at all 16:09:31 I don't know, but I do know that the test suite passes if we enable futexes. 16:12:36 true 16:13:41 We're somehow losing a wakeup condition, aren't we? 16:14:12 that's what it sounds like (aside from the delayed SIGUSR2, which i'm still suspicious about) 16:14:39 In order for that to happen under the WAIT-FOR (polling) regime, we have to be setting some bit of shared state without a suitable lock, don't we? 16:14:57 btw, /bin/bash -c 'kill -l' is a more convenient way to list signal numbers. 16:15:02 yes 16:15:20 or that sounds like the most obvious answer 16:15:23 foom: /bin/kill -L gives a substantial list. 16:16:04 so it does. I guess it's just zsh's kill builtin that sucks. 16:16:05 nyef: this seems to mostly affect semaphores, right? 16:16:40 Our working assumption is that a semaphore is involved, if that's what you're trying to ask. 16:16:41 have you double-checked that code generated for atomic-incf and atomic-decf in wait-on-semaphore is correct (actually atomic?) 16:17:09 I double-checked the VOPs, I didn't double-check that they were actually emitted. 16:18:02 I actually have to get some work done, unfortunately, so I'm going to have to let this rest for a few hours or possibly until tomorrow. 16:18:34 (And there's no chance of me getting anything done on this over the weekend other than another desk-check of the code.) 16:18:34 ok 16:18:45 Thanks, though. 16:18:55 We'll get this figured out yet! 16:19:22 i'll probably commit this anyways, since it doesn't seem to make anything worse, and the missing CAS lock is... missing now 16:20:12 Fair enough. 16:20:37 It's clearly an improvement, even if it's not a full fix. 16:21:11 I'll do the final commit to enable futexes by default, if you don't mind. (-: 16:21:21 (Once we have this all figured out, that is.) 16:23:57 not at all 16:34:04 ok, am going to update my libc 16:35:05 that's a statement that is usally followed by a tale of woe... 16:35:51 erm, it's on the slackpkg upgrade-all list.... 16:37:39 ah, that's different 16:38:07 it's "i'm going to upgrade libc manually" that tends to end badly 16:38:48 oh yes, i know, manually i would do it only on LFS.... 16:41:45 -!- homie [~levgue@xdsl-78-35-182-134.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 16:49:54 homie [~levgue@xdsl-78-35-182-134.netcologne.de] has joined #sbcl 16:55:31 Qworkescence [~quad@184-96-79-161.hlrn.qwest.net] has joined #sbcl 16:55:33 -!- Qworkescence [~quad@184-96-79-161.hlrn.qwest.net] has quit [Changing host] 16:55:33 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 17:07:54 hmm, new libc has no effect on the threading issues tho..... 17:11:31 ... more threading issues? 17:13:48 homie: what platform, what issues_ 17:13:52 ? 17:14:05 A slackware of some sort, apparently. 17:14:26 arch, build options, sbcl version, etc 17:14:37 nature of issues 17:14:54 (Is it merely issues, or is it a subscription?) 17:15:44 well, it's 2 failures, the ones like alpha 17:15:57 wait i'll post the build and test log 17:16:01 Oh, right, the two test failures on x86? 17:16:39 Seriously, man, the verify-backtrace thing almost HAS to be a deficiency in the backtrace machinery. 17:17:52 does break the same way it breaks on darwin? 17:19:01 build.log is at http://www.filedropper.com/build_2, and tests.log is at http://www.filedropper.com/tests_1 17:19:12 yes it is the same issue as on darwin i think.... 17:19:16 ie. the backtrace is stunted, but if you remove :timeout nil from the expected frame bit, you get the correct backtrace --- which no longer matches the expected one because it has :timeout nil and the expected frame does not? 17:19:21 nikodemus_: semaphores everywhere would probably help. 17:19:56 pkhuong: you mean re. my "less GC deadlocks on darwin" commit? 17:20:28 homie: that is not a threading issue. like nyef says it's a debugger/backtrace issue 17:20:34 nikodemus_: yup. 17:20:43 especially mach semaphores. 17:20:45 oh ok 17:21:05 pkhuong: apple says that mach semaphores aren't signal handler safe... 17:21:16 even post? 17:21:33 if so, we're screwed because timed_wait doesn't work on posix semaphores. 17:21:40 i don't think they specified. let me go look 17:21:49 pkhuong: we don't need timed_wait inside the runtime 17:22:48 "Semaphores can be used any place where mutexes can occur. This precludes their use in interrupt handlers..." 17:22:59 I'd like to see how sem_post is implemented if mach semaphore post isn't signal handler safe... Oh well. 17:23:13 not sure if that's really talking about kernel stuff or userspace mach handlers, or bsd layer signal handlers, though 17:23:45 they only document mach semaphores for kernel extension purposes, so the context is a bit vague... 17:24:21 pkhuong: possibly their posix semaphores just spin and sleep... 17:25:56 aargh. /some day/ i will make it so that make.sh will run clean.sh -- or at least enough of it that switching arches, etc between make.shs doesn't break the build 17:26:39 nikodemus_: I usually use my own build-sbcl.sh wrapper which picks an appropriate XC host, runs clean, and so on. 17:52:07 nyef: i managed to produce what /looks/ at first blush like a lost wakeup on x86, but might turn out to be something else 17:52:14 i'll dig in tomorrow 17:52:32 Okay. I might have chance to look into it this afternoon/evening. 17:54:07 nyef: ok. try running the mailbox.interrupts-safety test in a loop 17:59:50 -!- nikodemus_ [~nikodemus@cs181056239.pp.htv.fi] has quit [Ping timeout: 252 seconds] 18:01:04 -!- tyson2 [~Ian@76-10-173-74.dsl.teksavvy.com] has quit [Quit: Leaving.] 18:42:41 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 18:42:41 -!- ChanServ has set mode +o nikodemus 18:58:59 -!- akovalenko [~anton@95.72.175.8] has quit [Remote host closed the connection] 19:12:40 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Read error: Operation timed out] 19:13:21 -!- pkhuong [~pkhuong@gravelga.xen.prgmr.com] has quit [*.net *.split] 19:13:21 -!- sshirokov [~sshirokov@ghanima.slavasaur.com] has quit [*.net *.split] 19:13:24 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 252 seconds] 19:13:28 pkhuong [~pkhuong@gravelga.xen.prgmr.com] has joined #sbcl 19:14:33 sshirokov [~sshirokov@ghanima.slavasaur.com] has joined #sbcl 19:20:28 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 19:20:33 -!- ChanServ has set mode +o nikodemus 19:21:04 what is the platform compile option for x86-32 ? for threads -fPIC ? 19:21:33 i don't see any x86-32 in run-compiler.sh ? 19:21:34 No, -fPIC is for position-independent-code. 19:21:55 And the option to enable pthreads varies based on host OS. 19:22:13 On some, it's as simple as linking with -lpthread, IIRC. 19:22:46 erm, have done the threads.impure.lisp in interactive mode, loaded all the necessary files, and there was no problems.... 19:23:11 heh, must be something else intervening really 19:23:59 and debug.impure.lisp succeeded without problems too now 19:25:38 oh got a sigsegv loading callback.impure.lisp tho 19:25:58 unhandled condition in --disable-debugger mode... 19:28:27 http://paste.lisp.org/+2P5V 19:29:42 and the file exists! 19:31:39 homie: then it's best accompanied with ls -l /full/path demonstrating it does 19:32:21 homie, even 19:32:47 ok http://paste.lisp.org/+2P5W there it is 19:33:56 that's not what i asked for, you realize 19:34:18 no i don't 19:34:25 what do you mean ?= 19:35:00 ls -l /full/path/copied/from/the/error/message 19:35:49 not a directory listing where current directory has to be inferred from the prompt, which might or might not be true 19:36:19 oh man, i'm in the test directory and did a file listing.... 19:36:30 and it's no different from the error message 19:36:49 /mnt/hd/sources/boinkor/sbcl/tests 19:37:32 homie: so you're saying the error doesn't exist? or that you see no reason for the error to exist? (: 19:37:41 is callback.impure.lisp supposed to fail on its own in any way ? 19:37:42 do the test, convince yourself that it can't happen (: 19:38:04 homie: that's perfectly possible, but there's no way for me to tell for sure from that - nor do i want to read the full listing 19:38:24 is that some weird networked file system by any chance? 19:38:56 if you do the specific ls -l, the results are easier for us to interpret 19:39:14 first rule of debugging: rule out the obvious. then double check. 19:39:25 ok here you have it again http://paste.lisp.org/+2P5X 19:39:37 ls -l on the file with full path 19:39:58 what is that file system, then? 19:40:04 ok ok, i'll remember that in the future 19:41:04 but hey i'm not listing an unkown source jungle, you all knew that dir in and out i'm sure.... 19:41:36 know* 19:41:58 homie: the current directory can change from under you for various reasons (rm -rf for example) - never trust it! 19:42:07 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Read error: Operation timed out] 19:42:22 homie: that's not the same path 19:42:23 ok that's true, sometimes one forgets a cd in the meantime etc..... 19:42:34 well but you see that's not the case 19:42:38 the one in the error doesn't have sbcl/ in it 19:42:41 so what's happending there ? 19:42:43 I often do "cd `pwd`" before scratching heads (: 19:43:25 which is why i asked you to /paste/ the path from the error message to ls -l 19:45:08 anyways, it's getting late here. laters 19:45:15 oh i got it 19:45:16 ok 19:46:57 running again, i obviusly made an error 19:48:43 but however, weird that it segfaulted, just by a wrong path! 19:53:54 ok callback.impure passed 20:03:52 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 240 seconds] 20:09:37 i think it pays out to do some of the tests interactively or in isolation.... 20:12:14 I've started wishing to be able to run just one test from a file from the command-line. 20:12:24 But we're -really- not set up for that. 20:14:50 prxq [~mommer@mnhm-4d0108d1.pool.mediaWays.net] has joined #sbcl 20:15:11 erm, i fired sbcl, loaded test-util.lisp and assertoid.lisp in the test directory manually and then loaded some of the tests one by one.... 20:15:17 hi 20:15:34 mostly those named .impure.lisp 20:15:59 unwind-to-frame-and-call.impure.lisp has errors for example 20:18:26 What's up with u-t-f-a-c? 20:19:36 threads.impure.lisp ? 20:19:49 and debug.impure.lisp passes... 20:19:56 interactively 20:22:20 unwind-to-frame-and-call. 20:23:17 oh ok, wait 20:23:23 i'll paste the test run 20:25:49 http://paste.lisp.org/+2P61, there it is 20:27:38 I'd chalk that up to environment leakage. You probably have a proclaim with a type for *foo*. 20:30:07 -!- cmm [~cmm@bzq-79-181-67-31.red.bezeqint.net] has quit [Ping timeout: 248 seconds] 20:32:11 cmm [~cmm@109.67.65.220] has joined #sbcl 20:33:35 Yeah, you loaded symbol.impure.lisp in the same image, didn't you? 20:34:21 hmm, yes seems so 20:34:26 There's a reason that the test runner spawns a new instance for each impure test file. 20:35:12 oh 20:35:41 heh, good to know, since i would expect the environemnt to leak as default then....lol 20:36:13 didn't look at the test runners strategy 20:36:53 ok then, my way of testing one by one is flawed..... 21:10:05 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 21:10:05 -!- ChanServ has set mode +o nikodemus 21:13:03 milanj [~milanj_@109-92-105-240.dynamic.isp.telekom.rs] has joined #sbcl 21:15:53 hi, is memory leak issue if i'm seeing totally wrong memory usage value (with ROOM) ? 21:16:13 couse with linux top/ps value is 10x higher 21:16:33 which column are you looking at? 21:16:46 RES 21:17:54 You probably want to look at RSS. 21:17:57 -!- cmm [~cmm@109.67.65.220] has quit [Ping timeout: 244 seconds] 21:18:57 cmm [~cmm@109.67.65.220] has joined #sbcl 21:19:23 rpg [~rpg@mpls.sift.info] has joined #sbcl 21:20:01 and even then, some memory may not be unused but not (yet) released to the OS. 21:21:39 805MB, and ROOM is giving me yeah, it's the same 21:21:46 ups, sorry 21:21:49 RSS is the same 21:22:11 right, sorry. 21:22:25 confused by the top notation. 21:22:50 it's slowly growing for past 4 hours 21:23:08 I should probably create small test case 21:24:23 nikodemus solved much faster leak yesterday, it was hitting 1.6GB of memory in 20 minutes (heavy threaded http client), now it's slower but feels the same 21:32:46 maybe you're leaking foreign memory? 21:33:21 if room and rss are the same... 21:34:04 ah, that's not how I read the problem description :-) 21:35:09 turns out they are pretty close, actually. 21:38:04 milanj: what was the source of that leak? 21:38:25 milanj: I mean the one that you say nikodemus fixed 21:38:42 getprotobyname 21:38:44 or something similar 21:38:45 prxq: bad coding when getprotobyname_r needed more than 1000 bytes. 21:39:02 ok 21:39:10 pkhuong in normal cases as well, actually 21:39:14 oh right. 21:45:48 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Quit: Leaving] 21:46:11 I'll try to supply test case, in a meantime I guess I'll need to restart process every couple of hours since this should work for days ... 21:47:45 is this bug present in older versions? 21:49:41 prxq: yes. 22:04:14 -!- homie [~levgue@xdsl-78-35-182-134.netcologne.de] has quit [Read error: Connection reset by peer] 22:05:15 homie [~levgue@xdsl-78-35-182-134.netcologne.de] has joined #sbcl 22:09:30 -!- rpg [~rpg@mpls.sift.info] has quit [Quit: rpg] 22:34:52 -!- blumbri [~blumbri@c-67-181-176-186.hsd1.ca.comcast.net] has quit [Ping timeout: 258 seconds] 22:39:25 antgreen [~user@bas3-toronto06-1177889983.dsl.bell.ca] has joined #sbcl 22:55:16 -!- prxq [~mommer@mnhm-4d0108d1.pool.mediaWays.net] has quit [Quit: good night] 23:44:57 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving]