| Noskcaj | Should we add arm64 to the xubuntu-meta package before saucy releases? Or should i make a fix ready for merging as soon as t-series branches appear? | 07:51 |
|---|---|---|
| Unit193 | Adding another arch at the last second, with zero testing the entire cycle, and I'd guess nobody to take a quick run over at the last second anyway. | 07:53 |
| elfy | Personally I'd wait to see what the consensus is on the first question before working at all on the second | 07:54 |
| elfy | and +1 Unit193 | 07:54 |
| Noskcaj | makes sense. | 08:04 |
| brainwash | it's possible to hibernate system during live mode via menu, but not after the actual installation of (x)ubuntu | 11:29 |
| brainwash | a bit confusing | 11:29 |
| elfy | a bit pointless as well :) | 12:00 |
| skellat | Noskcaj: The only thing in the wild with an arm64 chip is the iPhone 5S so, no, I don't think it would be especially worthwhile for us to put that on our release manifest at the moment for 13.10. | 13:43 |
| elfy | skellat: he's not here ;) | 13:44 |
| skellat | elfy: That's what I get for reading buffered backlog via ZNC several hours later | 13:44 |
| elfy | :) | 13:45 |
| skellat | Still, the point remains that the only arm64 chip in the wild touching consumer hands is in the iPhone 5S right this second so adding support in isn't worth it for 13.10 | 13:45 |
| elfy | I don't see much need to do it all tbh | 13:46 |
| skellat | Conventional armhf got thrown under the bus as it was | 13:46 |
| elfy | yep | 13:46 |
| skellat | Now is supposed to be the chill-out period...test, look for hyper-critical issues that need last-minute fixes, test, and chill-out | 13:47 |
| jjfrv8 | Has anyone else seen this message on the users' list? https://lists.ubuntu.com/archives/xubuntu-users/2013-October/006065.html | 14:18 |
| jjfrv8 | I get slightly different symptoms but I can confirm the problem on two different host machines. | 14:19 |
| jjfrv8 | And it seems to happen with Saucy and not Raring. | 14:19 |
| brainwash | jjfrv8: maybe worth filing a lp report | 14:56 |
| jjfrv8 | brainwash, I was prepared to do that but I was afraid it would get shot down as a vbox issue. Doesn't seem like that to me, tho. | 14:59 |
| brainwash | I'll try to reproduce this one later, but some sort of bug report would be still needed | 15:03 |
| jjfrv8 | Sure. I'd be glad to do it. | 15:05 |
| slickymaster | afternoon all | 15:31 |
| thad | slickymaster: the users-admin segfault, the xfce4-terminal encoding menu one, and many others are all caused by glib 2.37 and newer | 17:28 |
| slickymaster | thad, do you mean, also https://bugs.launchpad.net/ubuntu/+source/xfce4-terminal/+bug/1206739 and https://bugs.launchpad.net/ubuntu/+source/xfce4-indicator-plugin/+bug/1181134 | 17:31 |
| ubottu | Ubuntu bug 1206739 in xfce4-terminal (Ubuntu) "xfce4-terminal crashed with SIGSEGV in magazine_chain_pop_head()" [Medium,Confirmed] | 17:31 |
| ubottu | Ubuntu bug 1181134 in xfce4-indicator-plugin (Ubuntu) "xfce4-indicator-plugin crashed with SIGSEGV in g_type_check_instance_cast()" [High,Triaged] | 17:31 |
| thad | yea, there's something wrong with the memory chunk allocator | 17:33 |
| thad | the applications did not change, but glib got pushed to 2.38 in saucy | 17:33 |
| slickymaster | thad, ^^^ you're right about that | 17:34 |
| thad | maybe I can find a way to resolve this, well at least explain it somehow :) | 17:36 |
| slickymaster | thad, that would be great | 17:37 |
| ali1234 | thad: so do you know a version that worked? | 18:54 |
| ali1234 | attempting to build 2.36... | 18:59 |
| ali1234 | the build got all the way to the end, ran the tests, and then crashed out | 20:12 |
| ali1234 | after successfully completing every test | 20:13 |
| thad | ali1234: what a bummer :/ | 20:23 |
| ali1234 | i am trying to debug it now but it is difficult | 20:23 |
| ali1234 | when gdb suspends it the menu is still open which makes it impossible to click on any other windows | 20:23 |
| ali1234 | or do anything at all, including kill gdb | 20:24 |
| thad | what about valgrind? | 20:25 |
| ali1234 | i could run it in xnest | 20:26 |
| thad | well, sadly I'm not a real expert | 20:28 |
| ali1234 | got it | 20:29 |
| ali1234 | it crashes in a different place now though | 20:29 |
| thad | can you share any details? | 20:30 |
| ali1234 | http://paste.ubuntu.com/6233113/ | 20:31 |
| thad | yea | 20:31 |
| ali1234 | number 4 is a big wtf | 20:31 |
| thad | https://launchpadlibrarian.net/151908575/Stacktrace.txt | 20:33 |
| ali1234 | oh, i see, that's the problem | 20:33 |
| ali1234 | it's calling a callback and the pointer is totally nonsense | 20:33 |
| thad | so, what can we blame for this madness? | 20:35 |
| ali1234 | don't know :/ | 20:36 |
| ali1234 | the trace continues: http://paste.ubuntu.com/6233140/ | 20:37 |
| thad | maybe test the first 2.37 release and then do a bisect? | 20:39 |
| ali1234 | i don't know where to get that from | 20:40 |
| ali1234 | terminal_encoding_action_menu_shown looks like where it is crashing | 20:40 |
| thad | yes | 20:40 |
| ali1234 | so i will just add printfs until i find it | 20:40 |
| thad | g_slist_prepend | 20:41 |
| ali1234 | it's probably already corrupted by that point | 20:42 |
| thad | which point? | 20:43 |
| thad | so we have the for loop to fill the menu with the different encoding entries (GSList groups) | 20:45 |
| ali1234 | have you tested this bug without gtk the patched libxfce4ui installed? | 21:02 |
| ali1234 | for gtk3 indicators | 21:02 |
| thad | what do you mean? | 21:07 |
| ali1234 | well, xfce4-terminal has a dependency on libxfce4ui which we rebuild for gtk3 indicators | 21:07 |
| thad | the daily iso is affected, even the fedora 20 alpha | 21:07 |
| ali1234 | ok, just checking | 21:08 |
| ali1234 | the crash happens inside that loop btw, but not on the first loop through | 21:08 |
| thad | most likely everything what switched to glib 2.37+ I assume | 21:08 |
| thad | yes, not on the first loop run | 21:08 |
| ali1234 | item = gtk_menu_item_new_with_label (_(terminal_encodings_names[n])); <- crashes here | 21:12 |
| ali1234 | when n == 2 | 21:13 |
| ali1234 | which is "Baltic" in the build in string table | 21:13 |
| ali1234 | so, bad translation? | 21:13 |
| ali1234 | no, it still crashes if i remove the _() | 21:15 |
| thad | sometimes it does crash on the 3rd run | 21:16 |
| ali1234 | always :/ | 21:20 |
| ali1234 | hmm | 21:21 |
| ali1234 | in fact it crashes before that line ^ | 21:21 |
| ali1234 | oh wait | 21:22 |
| ali1234 | now it is crashing without looping at all | 21:25 |
| ali1234 | so then, race condition | 21:27 |
| ali1234 | this makes no seeeeeense | 21:30 |
| ali1234 | i think i need to flush stdout or something | 21:30 |
| thad | comment out this line: groups = g_slist_prepend (groups, item); | 21:31 |
| ali1234 | hmm | 21:33 |
| ali1234 | it crashes before that though | 21:35 |
| ali1234 | this really makes no sense | 21:36 |
| thad | yea, still no clue, what's going wrong | 21:37 |
| ali1234 | hmmmmmmmmm | 21:37 |
| ali1234 | so | 21:37 |
| ali1234 | what s happening here is it adds the radio item and says "the items are in groups" | 21:38 |
| ali1234 | at that point groups is empty | 21:38 |
| ali1234 | then it puts the items into groups | 21:38 |
| ali1234 | wait, no | 21:39 |
| ali1234 | even the code doesn't make sense here | 21:39 |
| ali1234 | item = gtk_radio_menu_item_new_with_label (groups, default_label); | 21:39 |
| ali1234 | groups = g_slist_prepend (groups, item); | 21:39 |
| ali1234 | groups = g_slist_prepend (groups, item); <- this line apears in a lot of places, but the very first one makes no sense and appears to create a recursive menu definition | 21:40 |
| ali1234 | but i need to check the api docs | 21:40 |
| thad | right, reading the api should help | 21:40 |
| ali1234 | so when you said comment the line, which one? | 21:41 |
| thad | the one in the outer loop | 21:43 |
| ali1234 | yeah, that's the only one that makes a difference. i still don't understand why though, or what groups is even supposed to be | 21:43 |
| knome | thad == brainwash? | 21:44 |
| brainwash | yes, that's me | 21:44 |
| knome | oki | 21:44 |
| ali1234 | it still crashes eventually | 21:44 |
| brainwash | different PCs | 21:44 |
| ali1234 | *** Error in `terminal/xfce4-terminal': double free or corruption (out): 0x00007fe5434d0340 *** | 21:45 |
| ali1234 | *** Error in `terminal/xfce4-terminal': corrupted double-linked list: 0x00007fe5434d0310 *** | 21:45 |
| thad | randomly? | 21:45 |
| ali1234 | seems like it | 21:45 |
| ali1234 | oh i get it | 21:45 |
| thad | didn't crash for me, well, I don't even know what removing this line actually does :) | 21:46 |
| ali1234 | groups is the group of radio buttons | 21:46 |
| thad | yes | 21:46 |
| ali1234 | it's the set of mutually exclusive options that the radio group belongs to | 21:46 |
| ali1234 | so it makes no sense to add anything other than radio buttons to it | 21:46 |
| ali1234 | so commenting that line is in fact the correct fix | 21:46 |
| thad | so there is a problem with the list, right? | 21:46 |
| thad | mmh, still weird | 21:47 |
| ali1234 | because it is trying to turn off a item whch is not a radio item | 21:47 |
| ali1234 | presumably this used to work but now causes a crash | 21:47 |
| thad | didn't cause any trouble in raring | 21:47 |
| ali1234 | well, one way to find out is to make a simple test | 21:47 |
| ali1234 | which i will now try to do | 21:48 |
| ali1234 | also try to see if i can get it to crash with just that line commented | 21:48 |
| ali1234 | bet i can't though | 21:48 |
| thad | you should add all these findings to the upstream report | 21:48 |
| ali1234 | can't seem to crash it | 21:49 |
| thad | nice | 21:50 |
| thad | well, I can't either :) | 21:50 |
| ali1234 | ok, added the info to the bug | 22:04 |
| thad | mmh, do we have to free some memory? | 22:04 |
| thad | just curious | 22:05 |
| ali1234 | what do you mean? | 22:05 |
| ali1234 | i'm still a little bit dubious of this code | 22:06 |
| ali1234 | but i don't know gtk enough to say if it is right or wrong | 22:06 |
| ali1234 | i would have expected creating a radio item and specifying the group would automatically add the item to the group | 22:06 |
| ali1234 | thus it should not be necessary to manually append things | 22:07 |
| thad | we create these items, don't we have to free the memory afterwards? | 22:07 |
| ali1234 | otoh the empty group is a null pointer, so i don't understand how it keeps that stuff sorted out | 22:07 |
| ali1234 | no, if we do that the menu will disappear | 22:07 |
| thad | so it's garbage collection? | 22:08 |
| thad | well, valgrind can tell :D | 22:08 |
| ali1234 | eh, not really | 22:08 |
| ali1234 | this function is building the menu | 22:08 |
| ali1234 | some other functions tears it down | 22:09 |
| thad | yea, but if we comment out the line, the item won't get added and can't be free afterwards, because it's not in the list... or? | 22:10 |
| thad | freed | 22:10 |
| ali1234 | it doesn't get freed through the group | 22:10 |
| thad | ah ok | 22:10 |
| ali1234 | the group is only used when you click on a radio item - it turns off all the other radio items in the group | 22:11 |
| ali1234 | all the menu items are in the menu and submenus, they get freed through that | 22:11 |
| ali1234 | that's why it crashes, because it calls turn_off_radio_item() on something that isn't a radio item | 22:11 |
| ali1234 | at least that is my working assumption | 22:11 |
| ali1234 | anyway the groups isn't saved either | 22:12 |
| ali1234 | it's only stuffed into the radio items themselves | 22:12 |
| ali1234 | the only reference to any of this stuff, once the function finishes, is via the gtk window -> gtk menu bar -> ... pointers | 22:12 |
| thad | I need to learn more about C and GTK, it's a bit confusing without the right amount of knowledge | 22:15 |
| ali1234 | Gtk is incredibly confusing :( | 22:16 |
| ali1234 | castes everywhere | 22:16 |
| ali1234 | that's why stuff like this happens: you often can't tell what type of pointer you get - you have to just know and caste it appropriately | 22:16 |
| thad | invalid one :D | 22:16 |
| thad | ones | 22:16 |
| ali1234 | if you guessed wrong, it crashes | 22:16 |
| ali1234 | https://developer.gnome.org/gtk2/stable/GtkRadioMenuItem.html | 22:17 |
| thad | are you going to debug the users-admin segfault too? | 22:17 |
| ali1234 | maybe | 22:18 |
| ali1234 | looking at the example code there ^ it does seem like the items are added automatically to the group. i think this code smells funny | 22:18 |
| ali1234 | link to users-admin bug? | 22:19 |
| thad | wobug 1185396 | 22:20 |
| thad | bu 1185396 | 22:20 |
| thad | I give up | 22:20 |
| thad | this keyboard is so weird, not used to it | 22:20 |
| ali1234 | hmm this groups code must be okay - when you make a new item and pass in the group, it must update the group pointer in all the items in the group to point to the new group | 22:37 |
| ali1234 | because there's no other way it could work | 22:38 |
| ali1234 | and that is almost certainly what crashes | 22:38 |
| ali1234 | because the non-radio item doesn't have a pointer to the group list, so when it tries to set it... bang | 22:38 |
| ali1234 | that's why it crashes during setup, not when you actually click something | 22:39 |
| thad | so we wait until the fix gets approved upstream? | 22:39 |
| thad | because it makes sense now | 22:41 |
| thad | we could go ahead and include it before | 22:41 |
| ali1234 | hmm otoh it could be broken still :/ | 22:42 |
| ali1234 | or rather, it might only work by accident | 22:42 |
| ali1234 | this all boils down to a simple thing: GSList is a simple linked list | 22:42 |
| ali1234 | empty list is NULL | 22:42 |
| ali1234 | if you add an item to the empty list you get [item, NULL] | 22:43 |
| ali1234 | if you do it again, you get [item, NULL] again, but it is a different list | 22:43 |
| ali1234 | there is no way to store a reference to a GSList that updates all the copies of it | 22:44 |
| ali1234 | BUT this is only true when prepending | 22:44 |
| thad | why not append? | 22:44 |
| ali1234 | because you can't append to NULL | 22:44 |
| thad | mmh, ok | 22:45 |
| ali1234 | so i think what happens here is that every radio item has a different copy of the same list | 22:45 |
| ali1234 | in fact it probably ends up looking like a tree | 22:46 |
| ali1234 | i should just read the source and find out i guess | 22:46 |
| ali1234 | but at the moment... i still think this code is fishy | 22:46 |
| thad | still not sure, why g_slist_append() shouldn't work | 22:47 |
| thad | maybe I'm way too confused at this point | 22:47 |
| rowboatn1ck | what does "different copy of the same list" mean? | 22:49 |
| ali1234 | rowboatn1ck: linked list is a structure like { int: value; pointer: next; } | 22:49 |
| rowboatn1ck | without looking too hard, it looks like every radiobutton gets a pointer to the current element | 22:50 |
| ali1234 | not quite | 22:50 |
| ali1234 | we store a reference to the linked list as just a point. so to start with it is NULL | 22:50 |
| rowboatn1ck | yes | 22:51 |
| ali1234 | we prepend one item and we get pointer to: [{0xF00, NULL}] | 22:51 |
| rowboatn1ck | yes | 22:51 |
| ali1234 | let a = this pointer | 22:51 |
| rowboatn1ck | i dont think that happens | 22:52 |
| rowboatn1ck | i think its initally NULL, it gets passed, gets assigned an address to newly allocated memory | 22:52 |
| rowboatn1ck | the next iteration you pass that, it allocates a new again and assign | 22:52 |
| ali1234 | now prepend to a and we get pointer to: [{0xF01, a} -> {0xF00, NULL}] | 22:52 |
| ali1234 | prepend to a again and you get [{0xF02, a} -> {0xF00, NULL}] | 22:53 |
| rowboatn1ck | yes, but 0xF02's prev would be 0xF01 | 22:54 |
| ali1234 | no, it wouldn't | 22:54 |
| ali1234 | a doesn't change | 22:54 |
| ali1234 | you get a new pointer back | 22:54 |
| ali1234 | but the old pointer still points to the same thing as before | 22:55 |
| rowboatn1ck | in lack of a better term, the "old pointer"'s 'next' still points to NULL? | 22:55 |
| ali1234 | yes | 22:56 |
| rowboatn1ck | that is very, very odd | 22:56 |
| ali1234 | it's how linked lists have worked since forever :) | 22:56 |
| ali1234 | i'm going to have to code to up to see what really happens | 22:56 |
| rowboatn1ck | no, what would happen is, you pass NULL, it creates a node, set next to NULL | 22:57 |
| ali1234 | because basically however it works, this code is wrong imo | 22:57 |
| ali1234 | yes | 22:57 |
| ali1234 | then returns the node | 22:57 |
| rowboatn1ck | but if you do it again, the SAME node as *this*, should NOT be NULL | 22:57 |
| ali1234 | if you pass in NULL again you get a new node | 22:57 |
| rowboatn1ck | I would imagine, in this example, it worked like this: pass NULL, get address to current node, next iteration, pass that address, get address to new node, and again and again | 23:00 |
| ali1234 | yes | 23:03 |
| ali1234 | but that is not what xfce4-terminal does | 23:03 |
| ali1234 | http://paste.ubuntu.com/6233700/ <- is the prepend function | 23:04 |
| ali1234 | when you prepend some data, it makes a new node and makes it point to whatever list you passed in | 23:04 |
| ali1234 | so if you prepend the same data to the same list twice, you get two lists that share all but the first item | 23:05 |
| ali1234 | this is what xfce terminal is doing | 23:05 |
| ali1234 | when you make a new radio item it prepends itself to the list you pass in | 23:08 |
| ali1234 | then if the original list passed in was not null, it updates all the other radio items with the new list | 23:09 |
| ali1234 | xfce4-terminal then prepends the new item to the old list again, creating a new, different list | 23:09 |
| ali1234 | this is then passed in to the next item created, and so on | 23:09 |
| ali1234 | so each time you open that menu, it leaks a g_slist_node for each encoding type... which is bad | 23:10 |
| rowboatn1ck | i see | 23:13 |
| brainwash | so I wasn't wrong about the allocated memory not being freed? | 23:16 |
| rowboatn1ck | it shouldnt have to be free'd to do this | 23:17 |
| ali1234 | brainwash: no, you were wrong. it doesn't have to be manually freed. the function is actually allocating things twice and only one of them will be freed, the other is lost (there is no longer any reference to it) | 23:18 |
| brainwash | ah ok | 23:18 |
| brainwash | still bad | 23:18 |
| ali1234 | luckily the solution is very simple: just do it the way the example shows | 23:19 |
| ali1234 | brainwash: i added a patch: http://bug-attachment.xfce.org/attachment.cgi?id=5186 | 23:45 |
| brainwash | ali1234: reading your comment currently, impressive job, it explains everything :) | 23:46 |
| brainwash | patch looks ok, I'll test it later too | 23:48 |
| micahg | is anyone interested in helping to maintain blueman?/ | 23:49 |
| brainwash | micahg: just curious, what work needs to be done? | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!