Rocket2DMnbryce, changed package to xorg and attached 2 files.  it looks like a backtrace of some sort was included in the error log from the gdm folder, do you still need a full backtrace?00:00
Rocket2DMnill go ahead and start one, but feel free to interrupt if its not needed00:00
jcristaua full backtrace from gdb is a lot more useful for debugging than what's in the log00:02
Rocket2DMnrighto, getting the packages now00:02
jcristauthe log mostly helps narrow down the issue somewhat, and link multiple reports of the same bug together00:04
bryceyou'll need the dbg or dbgsym packages for each of the things mentioned in the X backtrace - xserver, hal, dbus00:09
bryceso far is looking like something input device related00:10
Rocket2DMnok, but how do i get the laptop to suspend when in gdb00:12
Rocket2DMni have a remote connection over ssh open00:12
Rocket2DMnshould i then go back to the laptop and suspend it?00:12
jcristauthat should work00:13
Rocket2DMnhmm i froze up the box00:13
brycelook at gdb00:13
Rocket2DMnyeah it broke00:14
jcristauhrm. keeping an ssh connection over suspend/resume isn't going to be easy..00:17
Rocket2DMnthe machine wont go to sleep while my ssh session is open00:18
jcristauin that case getting X to dump core will probably be easier than getting the trace in gdb00:18
Rocket2DMnthis is locking up the system00:20
bryceeh, I wish libc provided a full-backtrace printing capability00:21
bryceRocket2DMn: by chance does anything get saved to /var/crash/ ?00:21
Rocket2DMnim about to check there actually00:21
jcristaubryce: you want a libgdb? :)00:22
Rocket2DMndo i really need to do this gdb remotely?00:22
brycejcristau: that would be sweet :-)00:22
bryceRocket2DMn: not necessarily; sometimes you can do it from a console00:22
jcristauRocket2DMn: not if you get X to dump core when it crashes00:22
Rocket2DMnnothing in /var/crash, let me try from tty100:23
bryceyou may need to load the X binary and pass in X's args by hand (actually for debugging purposes you probably can skip most or all of the args)00:23
jcristauif you try it from tty1, type 'handle SIGUSR1 nostop' at the gdb prompt, otherwise you won't be able to vt switch00:25
Rocket2DMnok well i guess i cant do anything when i have gdb running, im stack at the blank screen again00:25
Rocket2DMnlol no you tell me00:25
Rocket2DMnjcristau, do i type that before cont00:26
jcristaui think running 'X -core', getting it to crash, and then looking into the core dump would be easier tho00:27
Rocket2DMnwe'll try that next00:28
Rocket2DMnok well i got it to suspend, but its not pulling out of standby, the power came back but the screen is black and i cant switch back to tty100:32
Rocket2DMni can ssh in, is my tty1 session recoverable?00:33
Rocket2DMnmaybe i should retry the whole thing in screen?00:34
brycedon't think you can recover tty's from ssh sessions afaik00:35
jcristautry 'chvt 1' in the ssh session then00:36
Rocket2DMndidnt think so, should i restart, do it all over, but from tty start screen, run gdb, detach, then trigger suspend? then pull out of standby and ssh and attach to screen?00:36
jcristaualthough, if X is crashed, gdb probably stopped it, so you can't vt switch..00:36
Rocket2DMnjcristau, no go on that, sorry00:36
jcristauhmm. the screen trick could work.00:37
Rocket2DMnalright, i gotta reboot the box again, give me a few00:37
bryceI've never seen that done before, but it's a slick idea00:37
bryce(if it works)00:37
bryceat this point I usually end up just slapping in print statements around where I think the crash is happening00:38
Rocket2DMnif this works, im getting a beer00:38
brycebrb (booting with new glib)00:40
Rocket2DMnoh man im in00:42
Rocket2DMnwe have a segfault kids00:43
Rocket2DMnhow do i pull all this out now is the question00:44
Rocket2DMni think it's going to take up more than the screen00:44
jcristauset logging, in gdb00:45
bryceyou can dump it to a log 00:45
jcristauor use screen logging, or whatever.00:46
Rocket2DMnok, well im already in a screen session with gdb open, x crashed, i ran "backtrace full" and there were about 3 screens of text00:46
Rocket2DMnhow do i grab all that and dump it to a file00:46
bryceset logging -- Set logging options00:47
bryceset logging file -- Set the current logfile00:47
bryceset logging off -- Disable logging00:47
bryceset logging on -- Enable logging00:47
bryceset logging overwrite -- Set whether logging overwrites or appends to the log file00:47
bryceset logging redirect -- Set the logging output mode00:47
jcristau'set logging on; bt full'00:47
Rocket2DMnso set a file first, right?00:47
jcristauwill log everything to gdb.txt00:47
Rocket2DMnah ok00:47
Rocket2DMnok guys, here is what we have - http://paste.ubuntu.com/102471/00:50
brycehot damn00:51
Rocket2DMnis that what we need?00:51
bryceyep, that's exactly it00:51
bryceI think I'm going to document your screen trick and name it the Imes Technique ;-)00:52
Rocket2DMnill attach it to the report00:52
Rocket2DMnbryce, =D.  ill explain on the bug report how i obtained the trace, in case anybody runs across it and needs to do something similar00:52
brycethat'd be wonderful, I'll copy it into our backtracing docs00:54
jcristau    prevSpriteWin = pSprite->win;00:54
jcristaupSprite is NULL, boom.00:54
jcristaubryce: fdo#1917600:56
jcristaulooks like the same issue. fixed by e1a3a1a0d85c9971aea65c2228b5fd4dbf3bf57a00:57
brycejcristau: cool01:02
bryceheh, what difference a bracket makes01:03
Rocket2DMnalmost done with my explanation, lol01:03
Rocket2DMnthis bug has already been fixed upstream? is that what im gathering?01:03
jcristauRocket2DMn: correct01:04
jcristauwith a one-liner01:04
bryceworse, just a set of brackets ;-)01:04
Rocket2DMnah, ive made worse errors in coding01:05
brycegreat, I'll pull that patch in once I'm done with this gnome bug01:05
Rocket2DMnok, i attached my backtrace to the bug report, i guess it can be marked as Fix Committed.  It would be cool if you can add the upstream report01:06
bryceRocket2DMn: sure I'll take care of doing that, thanks for doing such a thorough job on triaging this!01:06
Rocket2DMnno prob, learned a bit in the process01:06
bryceand of course thanks jcristau for locating the patch01:06
Rocket2DMnindeed, thanks for helping out jcristau , and bryce :)01:07
bryceRocket2DMn: then I hope you run into more X bugs :-) (ducks)01:07
Rocket2DMnhaha, i used to be able to troubleshoot X decently from xorg.conf, then all this autodetection took over01:07
bryceRocket2DMn: yeah, sometimes it can be a pain for troubleshooting issues, however on the other hand it eliminated having to help people figure out their h/v sync ranges, which was sort of a PITA (glad I mostly missed those days)01:33
bryceRocket2DMn: btw if you're interested in helping in triaging X crash issues and walking people through the steps you've done, I think you could help us sort out a lot of X problems.  01:35
Rocket2DMnsure bryce , holding down a real job limits my time to evenings01:49
Rocket2DMnwish i could do Ubuntu stuff all day though01:49
Rocket2DMnand i think youd all be glad to know, my beer glass here says "#include <beer.h>" on the side01:51
brycecool, even sorting out just one or two of these crashes a week can make a big difference in stabilizing X01:51
Rocket2DMnyeah ill keep it in mind when i make my way through the new bug listings when i get to them a couple of times a week01:52
Rocket2DMnmost of my time ends up going to the forums, and some wiki documentation ocassionally01:52
* bryce nods01:53
brycejust explaining to people how to get full backtraces can make a huge difference, whether in the bug tracker, forums, or whereever01:53
bryceas you saw, once we get a full backtrace, figuring out a solution often takes an X dev a few minutes01:54
Rocket2DMnyeah, people on the forums dont deal with bugs very much, except for the Development Testing area01:54
Rocket2DMnsome of us are working to integrate bugs better into that part of the community, but tbh they are mostly beginners who want nothing to do with them01:54
* bryce nods01:55
Rocket2DMni'm going to update my bug filing guide to include ubuntu-bug program at brian's request, http://ubuntuforums.org/showthread.php?t=101107801:55
Rocket2DMnforums were down a lot today, so i ended up doing the X thing instead of that01:55
bryceyeah even just reporting a bug requires some basic level of technical aptitude that not all users are ready to undergo01:55
Rocket2DMnX is even worse for beginners to handle because they don't ever want to see a terminal or tty, esp with no GUI behind it01:56
Rocket2DMnunfortunately the restricted drivers continue to be one of the major issues with new users, even almost 2 years now after i started with Ubuntu01:57
Rocket2DMnI have a silly question for you, what's the difference between xorg and xorg-server?  should most bugs be against xorg-server?02:00
jcristauxorg is a set of metapackages, mostly02:01
Rocket2DMnthought that might be the case02:01
jcristauso yeah, most bugs should be against the server or one of the drivers02:01
Rocket2DMni'll keep that in mind, thank you02:01
bryceit's okay to file against xorg; we routinely thumb through those and refile them to the appropriate product, but yeah nearly all bugs actually go against xorg-server or one of the drivers02:12
* Rocket2DMn takes notes02:12
brycemost people won't know what product to file against, so we don't make a big deal about it if someone just files against xorg (in fact we encourage doing so if there's ever any doubt), but it does add some delay to getting your bug reviewed02:13
Rocket2DMni was looking at the bugs for ubuntu-x-swat, they are almost all being handled02:14
Rocket2DMnthat's pretty impressive02:15
brycewell, actually we don't assign or subscribe bugs to ubuntu-x-swat anymore, so anything still there is going to be a fairly old bug02:16
Rocket2DMnyeah i noticed that, too02:16
Rocket2DMnis there another team that gets alerted of X bugs?02:16
brycenot really02:17
brycejoining ubuntu-x-swat gains you a feed of all the bugs02:18
bryceI've got several automated scripts that filter through new bugs, and bubble up ones ready for analysis (basically bugs set to Confirmed are ready to be investigated)02:20
Rocket2DMnbug 314838 looks pretty ripe for a backtrace02:21
ubottuLaunchpad bug 314838 in xorg "crash of xorg after vlc starts to play some movie" [Undecided,New] https://launchpad.net/bugs/31483802:21
Rocket2DMnill bookmark it for later though, i'm really tired02:22
Rocket2DMnI'll see you guys later, thanks for your help tonight with my bug, glad to know a fix is already on the way!02:24
brycecya! thanks again02:24
brycetjaalton: help!02:36
bryce$ git add 155_no_checkmotion_for_disabled_devices.patch02:36
bryceThe following paths are ignored by one of your .gitignore files:02:36
bryceUse -f if you really want to add them.02:36
brycefatal: no files added02:36
bryce*.patch is listed in .gitignore ?02:36
jcristauthat makes sense upstream. not so much for us :)02:39
brycejcristau: so should I -f it, or remove the *.patch from .gitignore in the ubuntu branch?02:45
jcristaui'd use -f02:46
brycedpkg-source: error: cannot represent change to xorg-server-ubuntu-git/hw/xquartz/bundle/Resources/English.lproj/main.nib/keyedobjects.nib: binary file contents changed02:58
brycehrm, seems ubuntu git maybe isn't in a buildable state at the moment03:00
jcristauyeah. timo mentioned that, apparently some binary files have been modified upstream, so they're not the same as in the tarball03:01
brycewell, patch applies fine and I'd be surprised if there were any build issues; I've pushed it up03:02
brycecan't build locally either...03:02
brycedpkg-checkbuilddeps: Unmet build dependencies: x11proto-dri2-dev (>= 1.99.3) libxv-dev03:02
jcristauthat's just a matter of installing them, no?03:04
bryceah, right05:50
brycesweet, we're below 1900 bugs :-)06:12
bryceand that doesn't include about 100 -intel bugs with no response that probably could be expired but that I'll give another week or two for responses06:14
tjaaltonbryce: yes, that's why we are still stuck with beta307:17
bryceheya tjaalton07:19
tjaaltonbryce: howdy07:22
bryceok no prob, I stuck a little cherrypick patch in there for when it's ready07:23
tjaaltonhmm redhat hired a nouveau developer.. interesting07:29
tjaaltonwonder if there'll be a release sometime :)07:30
crevettehello, good morning07:33
bryceheya crevette07:34
=== james_w` is now known as james_w
superm1bryce, i've got some hardware that I just got that again won't boot in vesa for intrepid, but does for hardy. NV doesn't yet support it yet. I can still make recommendations to that platform team for any enhancements necessary in the hardware, BIOS, or VBIOS to make it work, so can you look at the errors starting up with vesa to see if you had any suggestions that I could tell them? bug 31558818:33
ubottuLaunchpad bug 315588 in xserver-xorg-video-vesa "Hardware w/ 1600x900 LCD does not boot up using vesa" [Undecided,New] https://launchpad.net/bugs/31558818:33
superm1(also doesn't boot vesa in jaunty)18:33
=== ubott2 is now known as ubottu
brycesuperm1: looking19:58
brycesuperm1: will comment on the bug19:58
superm1bryce, thanks, i'll pass it on to the ODM then20:02
bryce(WW) VESA(0): Unknown vendor-specific block 020:05
brycemm haven't seen that before20:05
brycesuperm1: can you also post the xorg.conf you used for those logs?20:06
bryce(basically, I want to know if you specified any h/v sync ranges for either case)20:07
superm1bryce, it's basic live cd xorg log20:10
superm1bryce, so nothing special in terms of anything i specified 20:10
=== halfline is now known as krh
=== krh is now known as halfline
=== halfline is now known as krh
=== krh is now known as halfline
tjaaltonan excellent thread, great fun :)22:17
tjaaltonwell, at least the sixth post22:18
tjaaltonoh, gets better on the third page22:30
brycehe's complaining that the X api changed in the development release of jaunty??22:39
superm1what happens in the event that the new API isn't stable by the time jaunty goes out though?  I've got a bad feeling these vendors won't want to rev their drivers on an unstable api..22:47
tjaaltonwhat do you mean unstable? it hasn't changed in months22:48
superm1well is there a formal X release with the new API though, or is it all operating off git snapshots right now?22:49
tjaalton1.6 should be out soon, it should be finalized by then at least22:49
tjaaltonxserver is all you need, not the whole stack22:49
superm1right... but i'm saying in the hypothetical situation that 1.6 isn't released soon, and get delayed until say a month after jaunty releases22:50
superm1you know release dates slip etc22:51
tjaaltonin that case yes, they lose22:52
tjaaltonbut it's not likely22:52
tjaalton..that the release is delayed that much22:52
bryceI've a call with nVidia next week, I'll raise the issue22:53
tjaaltontoday there has been 34 commits to the 1.6-branch22:54
tjaaltonso a new rc could be out next week22:54
brycehowever I already notified them of the pending X version before christmas and encouraged adding support for it, and gave dates and such22:54
tjaaltonnvidia should be well aware of the ABI changes, since aplattner is quite active in the community22:56
superm1from my experience with them (at least the guys i've worked with), it's good to stay on top of things and ask for updates so they dont fall through the cracks22:56
tjaaltonwonder why they had support for 1.5 for months before the release22:57
tjaaltonsuperm1: did you notice bug 315632?23:12
ubottuLaunchpad bug 315632 in nvidia-graphics-drivers-180 "upgrade from 180.11 broken (trying to overwrite `/usr/lib32/libvdpau.so.1', which is also in package nvidia-glx-180)" [Undecided,New] https://launchpad.net/bugs/31563223:12
superm1tjaalton, <shrug> no, but i think that means it needs replaces then doesn't it?23:18
superm1not necessarily conflicts though23:18
superm1it's still in NEW, which is probably why no other reports have been made of it yet23:19
tjaaltonah, that's good so it can be fixed23:20
tjaaltonyes, replaces should be enough I guess23:20
superm1okay i'll do a quick tweak to it then23:20
tjaaltongreat, thanks23:21
brycetoo bad  users can't mark their own bugs as Wishlist23:23
brycemost of the bugs where people are unhappy about the automated triaging tools are because they're wishlist things23:24
brycewhich obviously don't require Xorg.0.log and the like, but hard to distinguish those from regular bugs mechanically23:24
brycehowever, out of 250 bugs or so changed last night, so far I've only seen 4 complaints of wrong triaging23:36
bryce"currently i don't have this problem except i think mesa, drm, and the23:41
bryceintel driver need some more work in general."23:41
tjaaltonclearly warrants a bug ;)23:48

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!