[05:11] RAOF: so, 1.13 is not in -proposed yet? [05:13] tjaalton: No; I got part-way through and then stalled on fixing up -ati. I didn't want to upload until I'd tested that it at least brings up a server on -ati, -intel, and -nouveau. [05:14] ok, cool. I have -intel to test on [05:14] though I bet you do as well :) [05:14] And this morning someone wanted help fixing up pointer barriers for Fedora! I couldn't possibly go past helping them out a bit so I don't have to :) [05:15] magcius?-) [05:15] Yeah [05:16] Are you back from your holiday? [05:16] yup :( :) [05:17] just when it got hot [05:18] (lowest during the night was 22C) [05:18] Oooh, urgh. [05:18] That is incorrect. [05:18] You should tell the weather to try again; this time, it failed. [05:19] hehe, yeah [05:19] well, there are still the weekends fully packed with activities, so there's time to get some of the "lost weather" back [05:20] it has been quite rainy and cool most of the july [07:42] morning [08:08] oh new intel drivers [08:14] RAOF: how's uploading going? I just pushed intel 20.2 update [08:14] hey [08:15] I'm trying to find out why my X server crashes every now and then when waking from suspend [08:15] heya [08:15] f [08:15] oops [08:16] I've got one crash dump that shows it segfaults on free() in Xi/xiproperty.c, in function XIDeleteAllDeviceProperties [08:16] that usually means memory corruption, can you try running X with valgrind? [08:16] mlankhorst: sure, how? [08:16] sec [08:17] create a script /etc/X11/X2 with these contents [08:17] #!/bin/bash [08:17] exec /usr/bin/valgrind --track-origins=yes --leak-resolution=high --malloc-fill=ef --free-fill=df /usr/bin/Xorg "$@" -verbose 10 &>>/home/yourusername/xorg-valgrind.log [08:17] make it executable [08:18] then remake the /etc/X11/X symlink, point it to /etc/X11/X2 [08:18] then just restart lightdm :) [08:18] to restore, sudo ln -sf /usr/bin/Xorg /etc/X11/X [08:19] ok, let's try [08:23] yeah, now running in valgrind [08:24] it's more useful if you install xserver-xorg-core-dbg and xserver-xorg-input-(evdev,synaptics)-dbgsym [08:25] what apt source I need for the -dbgsym packages? [08:25] https://wiki.ubuntu.com/DebuggingProgramCrash/ see Debug Symbol Packages [08:26] ah yeah, without those the stack traces show ??? [08:27] yeah for quantal I made -dbg packages so you would no longer need to enable that repo to debug most of X :) [08:27] heh [08:28] will I need a dbgsym package for the intel driver too? [08:28] intel_drv.so [08:28] if it shows up it would help [08:29] same for libdrm [08:29] yeah, both seem to show up [08:30] this will take some time, as the crahs doesn't occur every time when waking from suspend [08:30] usually once every two days [08:30] or so [08:32] what do you mean by a 'crash'? [08:32] you get the login screen? [08:32] tjaalton: yes [08:32] ok [08:33] actually I'm not sure if it's always when waking from suspend [08:33] sometimes the machine won't suspend and I get a login screen, so it happens when going to suspend [08:40] hmm, I still get ???'s from intel_drv.so [08:41] xserver-xorg-video-intel-dbg ? [08:51] and maybe libdrm.*-dbg [09:53] mlankhorst: nope, I still get ???'s [10:41] mlankhorst: I'm a bit confused by -ati and -evdev, but mostly evdev. What happened to 0005-fix-horiz-scrolling.patch 0006-axis-label-overrun.patch? They got added to a commit? And the git log is confusing; it's not a pre-sync to debian-experimental - there are still significant differences. [10:42] hm you're right, i wanted to sync evdev but they didn't want the patches, so no longer valid [10:44] Yeah. [10:44] It's probably also worth dropping the explicit depends on xserver-xorg-core; we don't need them. [10:44] RAOF: well I mesed up on evdev, first patch has to be manually unapplied with patch -Rp1, then you get the stable release again, to build against [10:44] mlankhorst: Hm, ok. [10:44] build system will reapply the patch [10:44] ati.. let me check [10:45] Yeah. [10:46] ati doesn't have an orig.tar.gz; there's no xf86-video-ati 6.99.99 release (right?), so it should have a ~git version so we can bump it if we want to grab a newer snapshot. [10:46] yeah [10:47] Also, I was also confused by the rationale; you said you grabbed a newer snapshot for some UMS fixes, but this is a kms-only release? [10:48] erm I meant it removes UMS, but there were some X server fixes after that that we need for building against x1.13 [10:48] Aaah. Ok, that makes sense. [10:50] but yeah I didn't know yet if I wanted to do another pull or not so I just set version to a stub [10:51] HEh. [10:52] everything more clear now? :) [10:53] So, another general comment - when pre-merging from Debian, it's nice if you include the (possibly incomplete) Debian changelog (complete with UNRELEASED), then add the Ubuntu changelog on top. [10:53] Yeah, everything more clear now. You could have committed the version number at the time you committed, though. There's no reason you can't change the version if you decide you need a newer pull ;) [10:54] aye but at that time I still had to update 25-ish other drivers, decided it was more easier not to handle everything as special if I could [10:54] Fair enough. [10:55] it's different if I just update -ati or -all [11:00] but I would rather have the new stack soon, I want to do a new push of the x-1.13 ppa, but for precise renamed, to test the mechanics I want to propose [11:03] Yeah. Now that's cleared up, I'll punch through it (tomorrow) [11:03] great :) [11:06] oh looks like new libXrandr landed too [11:45] mlankhorst: now it crashed [11:45] valgrind: m_mallocfree.c:288 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. [11:45] valgrind: Heap block lo/hi size mismatch: lo = 80, hi = 0. [11:45] This is probably caused by your program erroneously writing past the [11:45] end of a heap block and corrupting heap metadata. If you fix any [11:45] invalid writes reported by Memcheck, this assertion failure will [11:45] probably go away. Please try that before reporting this as a bug. [11:46] there are 52 invalid writes in the valgrind log :/ [11:55] Wow, you managed to crash valgrind with invalid memory access? Amazing! [11:55] I genuinely didn't know you could do that :0 [11:56] :) [11:57] the crash always happens after this log line: [11:57] (--) synaptics: SynPS/2 Synaptics TouchPad: touchpad found [11:57] just dump the full log somewhere [11:58] mlankhorst: https://gist.github.com/3206429 [11:59] what version of synaptics are you using? [12:01] mlankhorst: xserver-xorg-input-synaptics 1.6.2-1ubuntu1~precise1 [12:02] cnd: Arghhhhh synaptics is corrupting in that log again, updatetouchstate out of bounds, this time in the other direction [12:04] so this is a somewhat known prob? [12:04] I don't know, I can silence some warnings [12:06] one of the valgrind warnings there is known at least but I didn't isolate it to causing a crash, give me a sec [12:07] mlankhorst: ok, no hurry [12:07] I've had this issue for a long time [12:08] only now it started irritating me enough to look at it :) [12:09] ok how good are you with packaging? can send you a patch or updated package to test [12:09] dpkg-buildpackage :) [12:10] so yes, I believe I can build and install a package [12:10] if you send a patch [12:10] ok sure [12:11] http://people.canonical.com/~mlankhorst/229-strip-mode-pointer.patch this will shut up some warnings at least [12:12] if I backported it correctly, but I suspect it will not fix things enough [12:16] I'll have a try [12:16] thanks [12:18] how long has this been happening though, new breakage or old? [12:18] well, before july or after? [12:44] mlankhorst: before [12:44] I got this machine on february, and first used debian with gnome 3 [12:45] it had odd bugs (with synaptics) so I decided to try ubuntu [12:45] and ubuntu crashes :) [12:45] I installed it maybe two months ago, and the problem has been there all the time [12:46] ok [12:46] the package is building now, btw [12:46] else I was thinking the security update but I guess we could rule it out then [12:52] mlankhorst: yah, certainly not the last update [12:52] *yeah [12:52] if it still crashes one more time, which is likely, please update synaptics http://people.canonical.com/~mlankhorst/synaptics-dbg.patch , but I want to rule this issue out first :) [12:53] mlankhorst: ok [12:53] a lot of valgrind errors should be gone at least [12:53] too bad the only way to reproduce seems to be to suspend and resume 20 times... [12:54] you're helping a lot of others, I can't seem to reproduce it :) [13:04] now running 2:1.11.4-0ubuntu10.7~ppa :) [13:05] what if you touch keypad during suspend, ? [13:05] well, during start or end of suspend [13:20] mlankhorst: that sometimes makes it crash [13:20] but I'm not sure [13:20] the last time, for example, it crashed about 5 sec after fully waking up [13:21] akheron: can you give a valgrind log from that and then patch synaptics? [13:22] mlankhorst: that's the valgrind log I gave you [13:24] erm I just want to see if other errors are gone now :) [13:24] mlankhorst: and now with the xserver-xorg patch, I still get the same invalid writes in UpdateTouchState [13:24] ah [13:25] I'll post a new log, though i didn't crash yet [13:25] a sec [13:25] well the nice thing about the Xorg valgrind hook is that it records all attempts previously [13:26] so it doesn't wipe the log on X server restart [13:26] mlankhorst: remember we reverted a patch in precise [13:26] without those patches we will get touch update corruption I think [13:27] ok [13:27] mlankhorst: https://gist.github.com/3206891 [13:27] in this one, I suspended & resumed once [13:27] sigh looks like I have to figure out that failure, then [13:27] the errors are there but no crash yet [13:28] now I'll gotta go [13:28] will try the synaptics patch late today or tomorow [13:28] cnd: Sigh so really the only way to fix it is to find out why the whole patch series crashes on the backported input stack? [13:28] yeah [13:28] it's a simple null pointer dereference, but how it gets there makes no sense to me [13:29] hmm [13:31] and upstream was unaffected, let me see if I can find the packages I was using again [13:59] cnd: this was why it didn't make sense to me btw [13:59] (0x009508d0 in ActivateKeyboardGrab (keybd=0x21d2fd10, grab=0x220cfd80, time=..., passive=0) at ../../dix/events.c:1616 [13:59] (gdb) print *keybd [13:59] $1 = {public = {devicePrivate = 0x21c918a8, processInputProc = 0xa4cda0 , realInputProc = 0xa4cda0 , [13:59] enqueueInputProc = 0x947bf0 , on = 0}, next = 0x0, startup = 1, deviceProc = 0x649aa0, inited = 1, enabled = 0, coreEvents = 4, [13:59] deviceGrab = {grabTime = {months = 0, milliseconds = 1328245}, fromPassiveGrab = 0, implicitGrab = 0, activeGrab = 0x21d28ad8, grab = 0x0, [13:59] activatingKey = 0 '\000', ActivateGrab = 0x950750 , DeactivateGrab = 0x950570 , sync = {frozen = 0, [13:59] state = 0, other = 0x0, event = 0x21d30270}}, type = 3, xinput_type = 96, name = 0x21d304a8 "SynPS/2 Synaptics TouchPad", id = 14, key = 0x0, [13:59] valuator = 0x21d30ad8, touch = 0x21d326c8, button = 0x21d30580, focus = 0x0, proximity = 0x0, kbdfeed = 0x0, ptrfeed = 0x21d32568, intfeed = 0x0, [13:59] stringfeed = 0x0, bell = 0x0, leds = 0x0, xkb_interest = 0x0, config_info = 0x21d304c8 "udev:/sys/devices/platform/i8042/serio1/input/input7/event7", [13:59] unused_classes = 0x0, saved_master_id = 0, devPrivates = 0x21d2ff78, unwrapProc = 0xa4ac50 , spriteInfo = 0x21d2ff5c, master = 0x21bbfed0, [14:00] lastSlave = 0x0, last = {valuators = {683, 384, 0 }, numValuators = 4, slave = 0x0, scroll = 0x21d30bf0, num_touches = 2, [14:00] touches = 0x21d32c10}, properties = {properties = 0x21d34a10, handlers = 0x21d34a48}, transform = {m = {{0, 0, 0}, {0, 0, 0}, {0, 0, 0}}}, [14:01] why is it in processkeyboardevent for a touchpad? [14:01] don't know off the top of my head [14:01] but it may be correct [14:01] as odd as that sounds [14:01] ok [14:03] but spriteinfo was freed at that point, so that seems to be what it's dereferencing [14:05] are grabs supposed to be possible on disabled devices? [14:24] seems odd [14:27] I wish I could help out more, but I'm fighting a huge fire elsewhere right now :( [14:31] yeah it's the gimp crash [14:46] blindly looking through diff, isfloating seems to have added a check for !IsMaster(dev) upstream [14:50] other than that, tons of code churn from c99 initializers :/ [15:17] ok admitting defeat, I don't understand the input stack :) === shadeslayer is now known as shadeslayer_ === shadeslayer_ is now known as shadeslayer [18:21] mlankhorst: so I have no hope? :) [18:21] akheron: you do, you could go back to previous server-xorg 10.5 [18:21] but there's a crash you can trigger in that case [18:22] what crash? [18:22] bug #1021517 [18:22] Launchpad bug 1021517 in xorg-server (Ubuntu Precise) "Xorg-server crashes reproducible with GIMP usage" [High,Fix released] https://launchpad.net/bugs/1021517 [18:24] uh [18:25] akheron: the fun of having a weird stack :/ [18:28] well, if there's anything I can do... or should I switch to quantal? :) [18:29] would it help if I patched synaptics now? [18:34] it might :) [18:34] would at least enable more debug info [18:46] mlankhorst: [18:47] ../../src/synaptics.c: In function 'UpdateTouchState': [18:47] ../../src/synaptics.c:3126:35: error: 'struct SynapticsHwState' has no member named 'num_slots' [18:47] ../../src/synaptics.c:3127:69: error: 'struct SynapticsHwState' has no member named 'open_slots' [18:48] probably wrong member then, it should be clear from the code which one shouldbe used there but its end of workday and I have a headache :) [18:48] heh [18:53] mlankhorst: ok, got it to work [18:54] but how to build the .ddeb now? [18:54] -nc [19:00] now it crashes [19:00] (--) synaptics: SynPS/2 Synaptics TouchPad: touchpad found [19:00] BUG: triggered 'if (priv->num_active_touches >= hw->num_mt_mask)' [19:00] BUG: ../../src/synaptics.c:3120 in UpdateTouchState() [19:00] thought BUG_WARN was meant to be non-fatal [19:00] and then a segfault without printing the "Dumping slot state" message or anything else [19:01] ah well just remove that line [19:08] mlankhorst: [19:08] (--) synaptics: SynPS/2 Synaptics TouchPad: touchpad found [19:08] (EE) synaptics: SynPS/2 Synaptics TouchPad: Dumping slot state: [19:08] Backtrace: [19:08] ==24744== [19:08] ==24744== Process terminating with default action of signal 11 (SIGSEGV) [19:08] ==24744== General Protection Fault [19:08] ==24744== at 0x67BD801: __fprintf_chk (fprintf_chk.c:28) [19:08] :> [19:08] oh right [19:09] valgrind doesn't like that kind of thing [19:09] right just leave it be for now, I'll get back to you :) [19:09] ok