=== highvolt1ge is now known as highvoltage === cjwatson changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: [02:10] cjwatson, can I pick your brain for a second about the 'p' partition separator issue for dmraid device paths? [02:10] no point picking my brain at 2am [02:10] hi, it is _very_ hard to profile things without a frame pointer on x86_64, is there a way someone could be convinced to put actual binaries with them enabled in the dbgsym packages? [02:11] there's not much of it to pick [02:12] hehe... ok... maybe I'll catch you tomorrow ;) [02:12] you always seem to try to find me on IRC at this kind of time [02:13] it's not really very doomed to success - even if I'm here I'm only doing mindless things :) [02:13] hehe... I'll look for you in the morning ;) [02:14] was out of the house most of today... friend's had a baby [02:14] congratulations (by proxy) [02:14] hehe [02:14] is there an x86_64 "debug team"? it makes apport retracing pretty ugly too [02:15] right now i have to build everything myself or use 32bit, which isn't my daily driver [02:16] why is it any harder on x86_64? I thought the debug symbols had enough information to reconstruct the stack trace without frame pointers? [02:16] dbgsym packages are just stripped symbols, not a separate build pass [02:16] they can't use compiler options that the original binaries didn't use [02:17] for that matter, why is -fomit-frame-pointer even used on x86-64? makes sense with x86 since it has so few registers to begin with, but x86-64 has plenty.. how much difference does one more really make? [02:17] I'm not aware of it being the default; some package must be turning it on [02:18] `-O' also turns on `-fomit-frame-pointer' on machines where doing [02:18] so does not interfere with debugging. [02:18] psusi: it's part of the calling convention [02:18] unless that's the case on amd64, I don't know [02:18] but if it is, there should be no problem by definition [02:18] ohsix, eh? [02:19] ok here it is in another form: can someone be persuaded to enable it unconditionally for all packages [02:19] psusi: the x86_64 calling convention has something to say about frame pointers [02:19] I think we need a more specific report [02:19] ohsix, you mean it doesn't have one at all? [02:19] e.g. which packages have this problem? [02:21] cjwatson: all of X and its peripheral packages, pixman, cairo, transmission, rhythmbox (but this is just for now, i've tried profiling/debugging other packages to the same end) [02:22] ohsix, it looks like it has ebp to me... so it should be used [02:22] the x86-64 ABI does not specify whether a frame pointer is used or not. [02:22] ehhhh [02:22] that's what I thought... [02:22] just like x86 [02:22] "%rbp callee-saved register; optionally used as frame pointer" [02:22] the register is there and it is suggested you use it, but you don't have to [02:22] ok [02:22] http://www.x86-64.org/documentation/abi.pdf [02:23] right, thanks for looking it up; some windows brain damage might still be muddying my thoughts on the subject [02:23] hehe [02:24] so how to get me some -fno-omit-frame-pointer, in a manner that supersedes -On [02:24] I'm still curious though why it is any more annoying on 64 bit than 32? I thought that on 32 bit without frame pointers, you just couldn't get a back trace without debug syms, but with them you could? why is that any different for 64 bit? [02:25] looks like it's the default on x86-64, which implies (from the gcc documentation) that it is possible to do stack frame analysis without a frame pointer on x86-64 [02:25] so I think you need a better way to drive gdb or whatever, not -fno-omit-frame-pointer [02:25] sampling profilers need the frame pointer to figure out the calling sitel and it can unwind with them in each sample cheaply as well [02:26] well, it's sysprof, perf, oprofile [02:26] if you want to build with -fno-omit-frame-pointer, you'll need to rebuild stuff yourself [02:26] we're not going to make an Ubuntu-specific change to diverge from the general GCC world's defaults on this [02:27] if that were the case why don't up to date tools work at all? like, none of them [02:27] "if that were the case"> which statement of mine are you casting doubt upon? [02:27] you figure it might be one or two that work without frame pointers but with the "extra" undefined steps to the same end, but none of them do [02:27] profiling is usually the sort of thing a developer does, not an end user, so you are expected to just build with the frame pointer I think... [02:27] I've not noticed particular problems with gdb [02:27] the implication by gcc documentation [02:28] debugging != profiling [02:28] heh [02:28] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00300.html and thread is related [02:28] looking into why the packages are doing something in situ is debugging, and yo generally do it with a profiler [02:29] I agree with psusi. rebuild things locally if you need additional profiling facilities. [02:29] i just don't have _hours_ to find trivial problems that i want to report [02:29] hrm... yep, looks like -O2 definitely does turn off frame pointers... [02:30] rebuilding to get the information that you'd get with a frame pointer, for the stuff i'm looking at, rebuilds half the system [02:30] sorry === asac_ is now known as asac [02:30] looks like the frame-pointer decision was taken at a level well above Ubuntu in the toolchain world, and I don't think it would be appropriate for us to undo it [02:31] hrm... interesting.. I just compiled int main() { int x = foo(); return x; } with -O2 and it is only 2 instructions: xor %eax, %eax, and jmpq [02:31] it's not undoing it heh [02:31] it's "can you do this in situ" or not [02:32] if the profiler requires frame pointers, then no, you will have to rebuild locally to get them [02:32] rebuild the entire system [02:32] no, just what you are trying to profile [02:32] you can't add frame pointers to all the dbgsym packages without undoing the toolchain decision for the distribution in general [02:32] i'm just talking about the magnitude of the work in order to look at trivial things [02:33] getting detailed timing measurements on a function by function basis is hardly looking at trivial things ;) [02:33] psusi: the 3 applicatioins that are involved need like 50 packages rebuilt [02:34] only if you need to profile the entire stack, which isn't usually the case [02:34] i understand your position but i really can't belive you don't accept that it would be nice for fixing things if it was the other way around [02:34] it would be nice, but it's not going to happen ;) [02:34] need the X server, libdrm libdrm-intel cairo pixman libc6 gtk some gtk engines, transmission and some of its deps, and rhythmbox [02:35] there are many things I accept, but they generally tend to involve things where it's kind of in time to fix them [02:35] in this case it is far too late; the discussion should've been had way back [02:35] though I am curious why gcc decided to turn on omit-frame-pointer with -O2 on amd64... it doesn't seem like it would add much so I would have left it off [02:35] psusi: the people who did the x86-64 port thought it was a good idea [02:35] not so much "gcc decided" [02:36] cjwatson: i'll look into this some more; i've already read the old threads some time ago, but for a distro the cost in debugability is probably too high for any point made in them [02:36] ohsix: I have to say, this is never something I have run into [02:36] so I don't see it as a major cost [02:37] well you're not me, i try and triage every little bug i find with performance and there are a lot of them, and i can't often get satisfactory answers without days of work for even the most trivial among them [02:37] you're trying to make statements about the cost to the distribution for debuggability in general [02:37] i'm still confused about not having a frame pointer is a problem - gdb can give me a backtrace for anything if i have the debugging symbols [02:38] and I'm saying that I don't think the cost is that general [02:38] broder: sampling profilers sample ip and the frame pointer to unwind later [02:38] cjwatson: it makes perf useless [02:38] and that people doing this kind of sweeping performance work are likely to need to build substitute versions of packages anyway [02:38] so why couldn't they just capture the stack insted [02:38] ? [02:38] jesus christ, how the hell did gcc optimize this that much? this function doens't even have a stack frame! [02:39] unless you're doing performance analysis but not changing anything, which seems less useful [02:39] broder: 1000, 10000 times a second, even if they could, how would you read the traces? [02:39] set up an autobuilder to do the builds for you, it wouldn't take long [02:39] !ohmy > psusi [02:39] psusi, please see my private message [02:40] ohsix: you can post-process for a stack trace easily enough if that's what you want [02:40] psusi: leaf functions are beholden to their calling sites, and if they're idempotent they can be replaced entirely [02:40] broder: if you could, why doesn't perf, sysprof, oprofile or the other profilers do it? [02:40] presumably because nobody's implemented it yet? [02:41] broder: they need point in time samples, thats how they work [02:41] right. they need point in time samples of the stack trace. so take point in time samples of the stack, and backsolve [02:42] you know every monotonic time x and the information it yields is statistical [02:42] in any case, this discussion should be had with the gcc x86 backend maintainers and the maintainers of the profiling tools in question. Ubuntu's too narrow a forum. [02:42] ohsix: yes, i understand how statistical profiling works. you're still not explaining to me why it's not possible to do that after the fact if you can extrapolate a stack trace, which debuggers experimentally can [02:42] cjwatson: i don't propose changing the toolchain, that'd actually be pretty silly, it's just desirable for the stuff you actually run to let you introspect a bit [02:43] wow... well now I understand why amd decided that the caller should clean up the stack... that kind of upset me at first since caller cleanup usually generates smaller code.. I didn't think caller cleanup could generate both smaller and faster code sometimes [02:43] the stuff you actually run != the stuff somebody else actually runs [02:43] broder: if it was possible i'm pretty sure you could pick a maintained profiler today and get useful output with it [02:43] you can't make a coherent argument for which packages should have this treatment. this is why it's a toolchain decision [02:44] cjwatson: i guess, but not on anything else than ubuntu [02:44] it's a distro decision, they either care or don't [02:44] it would be unhealthy for Ubuntu to diverge from the rest of the x86-64 wowrld here [02:44] *world [02:45] while in principle distros can change anything, I don't agree that this should generally be a distro decision [02:45] the only argument i could make, which i haven't; is that i find i need to do this very often, and its with lots of packages [02:46] so you don't see the value in not having to rebuild half your system locally to do something that should be trivial? [02:46] ohsix, why do you frequently need detailed timing measurements for every single function that a large, complex program calls? usually you only profile the functions in the program, not every library it calls as well [02:47] psusi: while its not every, it is still a _lot_ [02:47] psusi: case in point 2 applications are making a third go nuts, and theres little indication which part it is [02:48] ohsix: I see the value, but it doesn't override other considerations [02:48] are there others? [02:48] there's also value in having our general optimisation strategy be at least vaguely similar to other distributions and to upstream! [02:49] sure [02:49] theres value in everything going upstream [02:49] http://old.nabble.com/x86_64-callgraph-support-td21947441.html is relevant [02:49] (sorry, nabble is annoying but I didn't find a better URL quickly) [02:49] points out that oprofile should be fixed to use dwarf2 unwind information [02:50] hm [02:50] and Andi Kleen knows what he's talking about for x86-64 [02:51] what about perf? it has it already [02:51] fix that, and now the profiler works better for everyone [02:51] cjwatson, since your brain seems to still be working pretty well, I'm going to throw the 'p' problem at you and see if you have any thoughts on it tonight, or can sleep on it. to sum up: dmraid and parted now always add 'p' before the partition number when figuring the device name for the partition. gparted and kpartx only add the 'p' if the previous char is a digit. They need to agree, so which method is right? [02:52] I don't have a clue, I've never been able to keep this straight :) [02:52] hehe [02:52] brb [02:52] I would tend to trust the lower-level tools, if that's the upstream behaviour [02:52] I know I need to patch something to fix this for natty, but I'm having trouble deciding which [02:53] does the kernel code have an opinion on this? [02:53] which is lower? dmraid and parted or kpartx? [02:53] the kernel just does what it is told... it doesn't care what you name it [02:53] hm, I would probably have said dmraid but I suppose I'm not certain [02:53] the kernel sometimes has defaults for device names [02:53] but someone said that other devices the kernel used ot have to name that could end in a digit it added the 'p' only if it already ended in a digit [02:54] cjwatson: since you talked me down a bit i'm gonna do more due diligence wrt. the tools i've been trying to use [02:54] perf: http://lwn.net/Articles/409797/ [02:54] that makes sense to me and to the gparted maintainer... so I'm tempted to patch dmraid and parted to do that [02:54] psusi: it's certainly more aesthetically pleasing the kpartx way [02:55] cjwatson: yar i saw it in the git log for the kernel [02:55] I agree [02:55] I'm a bit worried about the continuing device name transitions though [02:55] s/continuing/repeated/ [02:55] and causes less disturbance than always adding it... [02:55] ah, the clincher: - only support for x86-32. I need to split some arch specific code from [02:55] generic and add at least x86-64 support. [02:55] ohsix: right, but no suggestion that it isn't possible [02:55] well now i'm just angry :D cuz i have to rebuild anyways [02:56] psusi: who was it that made a comment on parted-devel about several different bits of software having been carefully lined up upstream to do the right thing here? [02:56] was it one of the LVM guys or something? [02:57] the real problem is the rhythmbox guys aren't taking my traces and the proof i've offered in many forms as evidence thatit's doing what i say it's doing; and i'd like to get it fixed [02:57] i think its the theme engine, transmission does the same thing but to a different degree; transmission just really pegs the x server doing it [02:58] if I were debugging that sort of thing I think I would work at the X protocol level rather than at the C call graph level [02:58] but perhaps I shouldn't armchair-quarterback you [02:59] my laptop is my daily driver & spending a dayor two building stuff is not my idea of fun, not to mention i don't have the bandwidth to commit to get the patches [02:59] i tried xtrace, it shows the operations but not why it takes so long in the server [02:59] perf would show traces all the way through if it worked [03:00] psusi: you seem to be already having the conversation upstream, anyway, and there've been quite a few knowledgeable responses on parted-devel etc. already [03:00] plus the fix wouldn't come from trace info from X, you'd sooner look to pixman/cairo, then the theme poking at it [03:01] that there are lots of probably useless messages at the connection level should be moot; cuz theres probably fixes in that area needed inboth the video driver and the theme engine [03:02] i might just have to throw my hands up until circumstances are different, fetching/building so much stuff is a blocker [03:02] psusi: Hannes' "linux scheme since the dawn of time" is the more aesthetically pleasing one, which is good I guess [03:02] ohsix: sounds like you have great motivation to improve perf :) [03:03] cjwatson: i don't know enough to judge if the effort is worth it; also the aforementioned "evidence", perf isn't good enough [03:04] oh, i do have a good suggestion for apport information to gather [03:04] get the theme engine name! [03:05] it has a ridiculous impact on things [03:05] the apport maintainer is not currently logged in hre - if you want to suggest apport changes, you'll need to file a bug [03:06] *here [03:06] sounds like a reasonable thing to collect [03:06] first bug i'll file is against rhythmbox :] [03:09] so how easy is it to rebuild everything without making a mess for a subset of the packages? i messed with apt-build to do it on a handful of packages, but that seems generally untenable [03:11] quite a bit of work's gone into sbuild et al; I'd use that if I needed this kind of thing [03:13] from what i do know i'd want to set the origin so it'd be easy to downgrade when i'm done, and at best provide just top level package names & have the deps handle themselves like apt does [03:15] cjwatson, if you mean a few days ago, that would be me ;) [03:17] cjwatson, I'm kind of disappointed at how few responses there have been though, especially from the redhat guys that maintain dmraid... I think the right thing to do is patch dmraid and parted, but I'd like some upstream approval [03:18] o noes skew [03:19] another question: is there a warning displayed when partman is having its way with the disk in ubiquity [03:19] I don't understand the question [03:20] resizing or rather, interrupting a partition resize is something that's bad to do [03:20] normally resizers are actually very careful to ensure that interruptions are safe [03:21] they have to be in case of power loss [03:21] i haven't seen the installer since 10.10 & i haven't resized since ever, but someone on the support channel interrupted it during a resize and lost his disks [03:21] then that should be a bug on the resize program, not patched around by UI in the installer [03:22] even if the resizer is perfect there are sill operations that aren't atomic and will trash the drive [03:22] its just bad luck for it to happen, but it's a real risk [03:22] oh nevermind... I see some responses now.. damn redhat mailing lists mangle reply-to header.. I didn't get the replies directly [03:22] such as? [03:23] heh [03:23] filesystems have metadata that aren't in sync in the same manner as they would be if they're mounted in the resizer [03:24] stopping in the middle of messing with the mft on ntfs can lose all of the directory entries on ntfs [03:24] ah, ok, an abort in resize2fs when moving the inode table would be a problem, true [03:24] I hate having to resort to UI warnings, but I suppose it might be necessary here [03:24] file a bug then [03:24] just a general question anyways, i know a warning would look bad and 99.99% of the time supefluous [03:25] alright [03:25] ideally we would determine when the resizer is in the dangerous bit [03:25] that may not be feasible [03:25] wait, how is it not interruption safe? resize2fs only adds or removes inode tables, not moves them afaik [03:25] i'd just hate for my grandma to lose photos or anything on the computer, even though its supposed to be a safe-ish operation [03:26] psusi: power interruptions can come after the OS has asked the disk to flush something, but before it has [03:26] thats not " [03:26] er, that's not [03:26] "vghfy89uhcgfyug [03:26] not the problem but it is the bottom line, sorry about that [03:26] psusi: see comment in e2fsprogs/resize/resize2fs.c above move_itables [03:26] key hitting enter with my pinky :] [03:27] search for "This is scary" [03:27] cjwatson: i dunno if the documentation is out there to find what operations are unsafe in reality on ntfs, and that'd be the big one [03:28] ohsix: in some modes, ntfsresize emits a warning when it's about to start with the unsafe operation [03:28] s [03:28] a power removal warning would suffice [03:28] search for resize_warning_msg in the source [03:28] cjwatson: ah cool [03:28] I thought that everyone understands that resizing a partition is inherently a dangerous operation and bad things happen if the power goes out in the middle, but that resize2fs tried to make sure it would be ok, and generally did a fairly good job of it [03:29] i will; you've giveb me a lot to do tonight [03:29] psusi: my mom doesn't, i do [03:29] psusi: the bulk of the resize (copying data around) is safe, but there's twiddling at the end that isn't [03:29] ARGH!@$ [03:29] psusi: i figure ubiquity is more for her than me :] [03:29] that single pixel border can't resize thing is really starting to get on my nerves [03:29] ohsix: the same problem would exist in d-i [03:30] cjwatson: sure, but i didn't help her put debian on the netbook i gave her [03:30] (d-i's used in Ubuntu too) [03:33] cjwatson, by move inode table, this code means evict inodes from the tables that are going away right? shouldn't they be copied to the destination, then the directories updated with the new inode number? so if interrupted then at worst you have the inode duplicated and either fsck should deal with that, or resize2fs should be able to resume? [03:34] the code comment says it's moving things in place [03:34] probably best to read the code if you have questions about it [03:34] I'm willing to take it at its own word that it's dangerous [03:34] ultimately it can't be done perfectly safely like a filesystem can make some failure assurances in how it works [03:35] the reason I don't want a warning throughout resizing is that the time-consuming part of resizing is typically implemented safely [03:35] what a real fs driver can do though, is have the inode in core while its messing with the file [03:35] cjwatson: right [03:36] something that just says anything about removing power should suffice [03:36] there's no reason it CANT be done safely... you might have to do some more work that will take longer, but... [03:36] psusi: you need some things to be atomic or restartable to be completely safe, you can't get that [03:36] resize2fs is not notorious for emphasising performance over safety [03:36] ohsix, sure you can [03:37] if you can make its phase 5 safe, I'm sure they'd take a patch [03:37] if resize2fs put shadow copies in the new place then updated metadata it could be safe_r_ [03:37] that's basically what I just said I thought it did [03:37] but like i said, the lowest common denominator is power removal [03:37] right [03:38] for smaller structures it might be fine [03:39] the mft on ntfs is a large part of the drive, you could fragment it in the process to make it safer, but i'd have to see what it actually does [03:39] i've never had an mft split on any resizes i've donr [03:39] as long as the mft doesn't have extents in the region you are truncating, you should not need to mess with it much when resizing [03:40] not with gparted anyways [03:40] right, but its supposed to be a percentage of the drive, the volume size & the mft is set as a ratio to support a certain number of files/directories [03:41] that's just a mkfs default thing... don't have to maintain it when resizing [03:41] it gets enlarged as needed [03:41] if you don't touch the mft you might not have any space for new files afer a resize [03:42] its moot though, if that's not what it does, i'll have to look [03:42] also iirc, there was a registry key or something you could tweak to change that default size so you could decrease it to leave more free space or reserve more for many files... basically like when you set the inode ratio with mke2fs, only the mft can grow dynamically [03:43] in fact i've got storage available i could just try it out [03:43] psusi: i know, but the thing is it takes 20% of the disk or more, depending on how many files are on it, my point was that if you hit the mft you could have taken all the space for actual files, and to grow the mft [03:46] OHHH! when enlarging a fs, the bg descriptor table grows larger, so for block groups that contain a copy, that will shove the inode table to the right [03:46] split mft is another problem [03:47] it by chance can end up in the end, and need to be moved; iirc ntfsresize takes this into account wrt. what it is able to resize, and wont let you shrink it lower than the end of the mft [03:47] ohsix, yea, that's what I thought [03:47] unless something is restartable theres always a power danger [03:48] it'd be awesome if they were though :D i see no reason why they couldn't, aside from lots of extra io for bookeeping and needing storage for it somewhere [03:48] I've been giving some thought to making e2defrag restartable, but it would make it so much slower and more complicated... [03:48] can't you just go by inode, then a restart is start at x? :D [03:49] it builds an entire new drive map in memory first, then starts relocating blocks from the old locations ot the new locations.... [03:49] xfs goes by AG then inode and it's just 2 integers to restart, but it's cheap to start again as well [03:49] ah [03:50] maybe you can whip up a magic hash to get rid of the map [03:50] that's why it's so fast ;) [03:50] if you have enough memory no block gets written more than once [03:50] and almost all of the IO is in large blocks... minimum seeking [03:51] right [03:51] if you have enough memory to hold it all, it can actually manage to rewrite the whole fs in one big read and one big write [03:51] that's the best way to do it if you have some guarantees about interruptions [03:52] copying and leaving metadata to be updated until the last moment then marking the old area empty takes extra copies [03:53] yea... and extra seeks... right now it reads all of the inodes, updates them, writes them back, then starts relocating blocks [04:02] err, wait.. that's what the resize inode is for.. [04:02] is that only needed for online resize? can resize2fs still work offline without the resize inode? [04:03] no idea [04:04] yes [04:05] ok, that makes sense then.. yea, phase 5 it says only runs if neccesary... not needed if you have a resize inode it sounds like [04:06] whoa... copyright ted and powerquest inc?... interesting... [04:06] cjwatson: http://lwn.net/Articles/380582/ [04:06] broder: you might like that as well [04:12] * psusi wonders what ever happened to that project to make a Linux equivalent of WinIce... that was one slick debugger [04:12] how do you get it to do that ^^ [04:13] ? [04:13] SchizoBunny|home: prefix your message with /me [04:13] ok thank you [04:14] ohh, hehe [04:15] anyways, with perf and sysprof the idea is to profile from the app all the way through the kernel, or between stuff in the kernel, the time it samples, how often it samples, and what it samples are hard constraints :[ [04:17] perf is _great_ too, it's a shame [04:22] someone posted an interesting problem this week with gdb on askubuntu.com... if you tell gdb to print strlen(something) you get garbage results... if you assign strlen to another pointer and use that to call it instead in the gdb expression, it works... === SchizoBunny|home is now known as SchizoBunny|ZZZ [04:24] different calling convention from the gdb stack frame setup to make the call from the sound of it [04:32] apparently systemtap works, but only with -fasynchronus-unwind-tables; how can i find out of that's set on ubuntu [04:33] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00337.html uhuhuh [04:37] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00342.html <- by who indeed [04:37] * ohsix keeps looking [04:37] it looks like h.j. lu just did it by fiat [04:41] cjwatson: apparently the 386 abi says the same thing about the frame pointer register and its optionalness, people writing unwinders just used it if it was there; and that didn't make it to x86_64 [04:41] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00223.html [04:43] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00354.html google engineers uncondtionally enable it on x86_64 [04:51] ohsix, from that mail it sounds like it's been the default on x86 for some time too and it suffers the same problem.. they are saying that profilers just need fixed to deal with not having a frame pointer [04:51] nah it was a proposal to enable it on x86 [04:52] sampling profilers that work in the kernel aren't going to be fixed for that [04:52] umm... I read it as a proposal to enable it on -64 and the response was that x86 has been doing it for a while and not had complaints? [04:52] exactly the opposite [04:52] and that if you fix the profiler for -64, x86 would benefit as well [04:52] yes [04:53] because _64 already has the proposed change [04:53] which is unconditional -fomit-frame-pointer [04:53] >>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86. [04:53] >> It doesn't for user space. The problem is that you would need [04:53] x86 already had it enabled [04:53] apparently async unwind tables are enabled on x86_64 by default too [04:54] psusi: that refers to oprofile, not gcc; it's a gcc list, the posts are about enabling -fomit-frame-pointer for x86 [04:55] ohh, I see now [04:55] I was going to say, I thought that if you wanted -fomit-frame-pointer you used to have to explicitly enable it [04:56] at least for -O2... -O3 turned it on iirc [04:56] it was discussed in 2004 as well http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01033.html [04:58] unfortunately there doesn't appear to be much discussion other than gdb working with dwarf info; gdb has an opportune time to read such things indeed ;] [05:04] http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01124.html holy hyperbole batman [05:04] poor guy === sabdfl1 is now known as sabdfl === JamesPage1 is now known as jamespage [10:37] ttx: ping [14:45] Hi guys, anybody knows algorithm to convert UTF-16 to UTF-8????? [14:49] in python, I'd just call something like unicode(a, 'utf-16').encode('utf-8') [14:49] anything in c or c++.. [14:52] gaurav_pawaskar, there are quite a few libraries for unicode conversion, like libicu [14:53] you might also want to use something like http://utfcpp.sourceforge.net/ for a lightweight solution [14:55] thank you artfwo... [14:57] gaurav_pawaskar: I'm not sure, but iconv might be able to do it - man 3 iconv === _LibertyZero is now known as LibertyZero [16:16] hi all [16:17] can someone take a look at https://bugs.launchpad.net/ubuntu/+source/libva/+bug/595661 ? [16:17] Ubuntu bug 595661 in mplayer (Ubuntu) "please support h264 hardware acceleration on certain intel video cards" [Undecided,Confirmed] [16:17] it would be great if libva could be synced from debian [16:23] ScottK: https://launchpad.net/~lamont/+archive/ppa should have 2.8.0-0.1 once it finishes cranking through the process [16:24] ScottK: it passed my smoketest, but it really needs a more thorough looksee before I'm comfortable uploading it, and that won't happen today while I'm sleepy... care to take a gander? [16:24] and actually, that's 2.8.0-0.1~lucid1 [16:32] Turl: libva sync has already been requested: bug #721978 [16:32] Launchpad bug 721978 in libva (Ubuntu) "Sync libva 1.0.8-3 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/721978 [16:33] debfx: nice, let's hope it makes it in time then [18:23] humm.. I would like to know why the indicator-applet-session is taking 468MB of ram on mu ubuntu 10.04 [18:23] *my [18:24] Otacon22: is that what smem says? [18:25] smem? [18:25] Otacon22: apt-get install smem [18:25] ok wait [18:25] in the meanwhile [18:25] USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND [18:25] otacon22 22433 0.0 6.0 829112 492468 ? Sl Feb06 17:23 /usr/lib/indicator-applet/indicator-applet-session --oaf-activate-iid=OAFIID:GNOME_FastUserSwitchApplet_Factory --oaf-ior-fd=32 [18:25] and i have 8 GB of ram. [18:26] otacon22@PhoenixDesktop:~$ smem | grep indicator-applet [18:26] 22434 otacon22 /usr/lib/indicator-applet/i 1132 27228 27629 35312 [18:26] 22433 otacon22 /usr/lib/indicator-applet/i 14852 484856 485257 492504 [18:26] The second one should be the right one [18:27] hm odd [18:28] can you post the output of /proc/22433/smaps to a pastebin [18:28] sure [18:29] http://pastebin.com/X0yNzxcB [18:31] nearly 500mb heap heh, that's probably a bug, is there something you can do to make it consume a bit more ram each time you do it? [18:31] I don't know, i'm looking [18:34] I'm looking the strace in real time [18:35] Humm, nothing interesting [18:35] What could i do to investigate more about it? [18:35] no idea, do you even use fast user switching? [18:36] never [18:36] i just lock the screen [18:36] theres some stuff on dbus exposed by it but i don't exactly know what, something could be using that [18:37] it's only using 5 megs here [18:37] but i use to keep the pc on for long time, and it seems to happen after long time [18:37] otacon22@PhoenixDesktop:~$ uptime [18:37] 19:38:41 up 16 days, 3:45, 25 users, load average: 0.83, 0.88, 0.77 [18:39] 25 users? [18:39] terminals right [18:39] you're using maverick right, and just regular gnome? [18:40] no, 10.04 lts [18:40] yes, regular gnome, standard theme [18:42] whatever it is, for only being 16 days it's happening pretty often, or it's a huge leak, dbus-monitor can show what might be invoking the indicator applet; and if it's not there i can't say much about what's left to look at :\ [18:44] signal sender=:1.72 -> dest=(null destination) serial=484535 path=/org/ayatana/indicator/session/menu; interface=org.ayatana.dbusmenu; member=ItemPropertyUpdated [18:44] int32 19 [18:44] string "restart-label" [18:44] variant string "Riavvia..." [18:44] there are a lot of this [18:44] "riavvia" is italian and means reboot [18:45] ok [18:46] install d-feet, you can look at :1.72 and see what binary it is coming from [18:46] (the ram used by the indicator is growing up) [18:47]