Back
[13:49:09] <BigJohnT> hmmm, the comp example files need to be re-worked...
[14:18:02] <jepler> bigjohnt: hm, they probably have to have 'license "GPL";' added, but besides that they should all still work
[15:58:52] <alex_joni> emc2-buildmaster: status
[15:58:52] <emc2-buildmaster> dapper-x86-2.2-realtime-deb: idle, last build 1802724 secs ago: build successful
[15:58:52] <emc2-buildmaster> dapper-x86-2.2-realtime-rip: idle, last build 1803700 secs ago: build successful
[15:58:52] <emc2-buildmaster> dapper-x86-2.2-sim: idle, last build 1803554 secs ago: build successful
[15:58:52] <emc2-buildmaster> dapper-x86-trunk-realtime-deb: idle, last build 62237 secs ago: build successful
[15:58:52] <emc2-buildmaster> dapper-x86-trunk-realtime-rip: idle, last build 62566 secs ago: build successful
[15:58:53] <emc2-buildmaster> dapper-x86-trunk-sim: idle, last build 62772 secs ago: build successful
[15:58:55] <emc2-buildmaster> hardy-x86-2.2-realtime-deb: idle, last build 1802877 secs ago: build successful
[15:58:57] <emc2-buildmaster> hardy-x86-2.2-realtime-rip: idle, last build 1803357 secs ago: build successful
[15:58:59] <emc2-buildmaster> hardy-x86-2.2-sim: idle, last build 1802512 secs ago: build successful
[15:59:01] <emc2-buildmaster> hardy-x86-trunk-realtime-deb: idle, last build 62413 secs ago: build successful
[15:59:03] <emc2-buildmaster> hardy-x86-trunk-realtime-rip: idle, last build 62209 secs ago: build successful
[15:59:05] <emc2-buildmaster> hardy-x86-trunk-sim: idle, last build 62772 secs ago: build successful
[15:59:07] <emc2-buildmaster> lenny-x86-trunk-realtime-deb: idle, last build 62229 secs ago: build successful
[15:59:09] <emc2-buildmaster> lenny-x86-trunk-realtime-rip: idle, last build 62589 secs ago: build successful
[15:59:11] <emc2-buildmaster> lenny-x86-trunk-sim: idle, last build 62780 secs ago: build successful
[15:59:16] <alex_joni> err.. I meant url :/
[16:12:02] <fenn> last build 20 days ago?
[16:13:13] <alex_joni> on 2.2 I suspect so
[16:13:51] <alex_joni> on TRUNK it's ~17h
[16:14:06] <alex_joni> which is about right since the last commit
[16:17:51] <alex_joni> jepler: how about building beta2?
[16:18:16] <alex_joni> I think it would be fine to do that (with the fixes for the issues from beta1), then maybe announce it to emc-users too
[16:26:48] <SWPadnos__> SWPadnos__ is now known as SWPadnos
[16:41:02] <cradek> I think beta2 at the end of the weekend, instead of now
[16:41:20] <cradek> mostly because I know I'll be using it and I might run into something else
[16:42:44] <alex_joni> end of the weekend is also fine for me
[16:42:51] <alex_joni> I'll be gone most of tomorrow though
[16:43:35] <cradek> oh ok, whatever you guys decide is fine. I don't think I'll run into anything, frankly
[16:44:02] <cradek> bbl
[16:44:03] <alex_joni> mostly gone during the morning/afternoon, but the evening is available
[16:44:13] <alex_joni> so just about when you start showing up in here :P
[17:10:28] <dgarr> re: halscope sigsegv - a better result and a patch:
http://filebin.ca/ydvs/halscope_06mar.txt
[17:19:05] <alex_joni> a patch sure sounds good :)
[17:21:17] <alex_joni> jmkasunich should probably know most about scope.c and scope_rt.c
[17:24:41] <jepler> alex_joni: I have to look at some stepconf stuff before beta2, but I haven't gotten around to it
[17:29:02] <alex_joni> anything I can help with?
[17:41:39] <cradek> dgarr: you found the key: move the trigger pos slider all the way down
[17:41:49] <cradek> it often segfaults for me here when I do that and then click force
[17:43:51] <dgarr> it took a while because i always restarted using the same config file
[17:44:54] <alex_joni> cradek: out of bounds on the trigger level?
[17:45:39] <cradek> I don't understand it yet
[17:48:40] <cradek> the same calculation you modified: pre_trig = ctrl_shm->rec_len * ctrl_usr->trig.position is in three places
[17:51:57] <dgarr> no ctrl_shm->pre_trig is the one that matters
[17:53:29] <dgarr> in the communciation between rt and user, the others are local/gui
[17:55:17] <dgarr> ctrl_shm->samples++ is not checked each time in scope_rt.c so samples++ can exceed rec_len if the slider is all the way down
[17:57:01] <dgarr> this eventually overwrites something or trashes the stack (i think)
[17:58:02] <cradek> with your hints I bet jmk will understand it. I'm lost in the code...
[18:13:27] <cradek> #0 0xb74eb9bc in memcpy () from /lib/tls/i686/cmov/libc.so.6
[18:13:29] <cradek> #1 0x0804c5b6 in capture_copy_data () at hal/utils/scope.c:352
[18:13:29] <cradek> #2 0x0804c60a in capture_complete () at hal/utils/scope.c:370
[18:14:05] <cradek> here is the overrun
[18:14:43] <cradek> ctrl_usr->samples is 1002, and it overruns when n=1000, like you say
[18:19:05] <cradek> jmkasunich: ^^
[18:19:12] <dgarr> writing on a stack frame kind of makes backtrace useless
[18:19:40] <alex_joni> dgarr: as I understand it, there's not much that can be done different
[18:19:46] <alex_joni> because of userspace<->rt comms
[18:19:48] <cradek> yes if you don't catch the overrun right away, it's sometimes pretty trashed
[18:20:09] <alex_joni> at least it didn't trash the scope_rt part
[18:20:19] <cradek> I caught this one with electricfence
[18:21:02] <cradek> I agree there's an off-by-two error somewhere - not sure just where, though
[18:22:20] <dgarr> s/writing/overwriting/
[18:23:13] <alex_joni> fwiw that line is there since version 1.1
[19:17:38] <dgarr> cradek: i was looking at the docs for electric-fence (now duma); i see it subsitutes its routines for malloc,calloc etc, does it do the same for memcpy? the man page doesn't seem to mention that
[19:19:44] <dgarr> nm *.a|grep -E malloc\|memcpy says it does
[19:20:21] <dgarr> i mean nm libduma.a|grep -E malloc\|memcpy
[19:35:05] <dgarr> overwriting the stack explains why the backtrace from gdb with dbg libs was so goofy
[21:19:09] <jmkasunich> dgarr, cradek: thanks for all the detective work
[21:19:31] <jmkasunich> I'm kind of buried right now (big project that I must finish and ship), but I'll dig into it as soon as I can