**** BEGIN LOGGING AT Sat Mar 31 03:00:01 2018 **** BEGIN LOGGING AT Sat Mar 31 06:46:37 2018 Mar 31 13:02:51 seebs: I've just confirmed that http://git.yoctoproject.org/cgit.cgi/pseudo/commit/?id=778abd3686fb7c419e9016fdd9e93819405d52aa causes librsvg to segfault during do_install Mar 31 13:05:52 seebs: I think its use of syscall() from libglib Mar 31 13:06:04 libglib-2.0 Mar 31 15:43:04 yeah, looks like it might be. Mar 31 15:43:19 it's gonna take forever to get there, because the test case is somewhere past cairo. Mar 31 16:22:06 huh, interesting. Mar 31 16:22:18 the actual failure i got from librsvg install isn't the segfaults. Mar 31 16:22:26 cannot write output files to `/home/seebs/src/poky/build/tmp/work/i586-poky-linux/glibc-locale/2.26-r0/locale-tree/usr/lib/locale/hsb_DE.ISO-8859-2/': No such file or directory Mar 31 16:23:12 ah-ahh! but i can reproduce that by running a single cross-localedef under pseudo. Mar 31 16:24:21 interesting. running cross-localedef under pseudo produces that. Mar 31 16:24:29 but running ls of the directory under pseudo doesn't. Mar 31 16:30:35 huh. this is weird. cross-localedef is emitting an error message about a path it hasn't referred to in any way for pages of output. Mar 31 16:33:30 seebs: I suspect the librsvg thing will reproduce if you make a local build of it and "make install" into some dummy location Mar 31 16:35:33 so, i'm not hitting the segfaults. Mar 31 16:35:55 or rather, i am, but they seem not to be what killed the build. Mar 31 16:36:14 i'm getting a weird failure from cross-localedef, and it makes no sense. Mar 31 16:36:29 specifically: i can compare with and without the path changes, and the failure happens only with the path changes. Mar 31 16:36:29 seebs: additional path problems in your build? :/ I haven't tested the latest commits you made Mar 31 16:36:51 but, and this is the neat part, the path it's reporting problems with *hasn't been used recently* when it fails. Mar 31 16:36:58 seebs: to be clear I was using latest master with and without the syscall change but only for librsvg Mar 31 16:38:24 yeah. my build trying to get there blew up on the path thing. Mar 31 16:39:28 the weird thing is just that, usually, when path stuff fails, the error message relates in some way to a path that pseudo has just been asked to resolve. Mar 31 16:39:56 in this case, it resolves the path successfully, and then i *don't* get any diagnostics about it, and it fails. Mar 31 16:40:14 seebs: that does sound very odd :/ Mar 31 16:40:48 seebs: I'll see if I can give you a faster svg reproducer Mar 31 16:41:08 ... ah-hah! Mar 31 16:41:14 i think i found a thing. Mar 31 16:42:04 strace suggests that something called lstat("") and got ENOENT Mar 31 16:42:18 seebs: ah Mar 31 16:42:26 that is the degenerate case i had not considered. Mar 31 16:42:36 seebs: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip2&id=1150df1a358e4787e781f478b583bed645e465f9 - if you bitbake librsvg-native it will reproduce the segfault Mar 31 16:42:54 being native it doesn't need the cross compiler or libc Mar 31 16:43:03 I just hacked the native install to run under pseudo Mar 31 16:43:32 hmm. that may not be the problem. Mar 31 16:43:41 cool. Mar 31 16:51:55 i am just so curious as to what is causing cross-localedef to suddenly assert that it can't open a thing, when it doesn't appear to have tried. Mar 31 16:53:16 oh geeze Mar 31 16:53:26 i think someone is actually checking errno to determine whether an error occurred Mar 31 16:54:25 yes Mar 31 16:54:34 okay cross-localedef is just plain wrong, but also i should fix my code. Mar 31 16:54:51 the problem is that the new path resolution code is more likely to call lstat on something which doesn't exist, and set errno to ENOENT. Mar 31 16:55:17 Whereupon cross-localedef, doing something else entirely, declares that an error occurred, not because a call returned an error status, but because errno is set. Mar 31 16:57:59 i would just like to take this opportunity to remind everyone that *errno being set does not indicate that an error has occurred*. Mar 31 17:03:08 seebs: such fun :/ Mar 31 17:03:26 hey, i'm happy Mar 31 17:03:36 i run a D&D game that started 3 minutes ago and I'm only slightly late and i fixed it Mar 31 17:04:02 I'll try to get to librsvg soonish, but probably not in the next few hours. I am urgently required to cause giants to hit people with large and heavy objects. Mar 31 17:05:17 seebs: np, go and have fun with giants! :) Mar 31 17:05:49 * RP should go and be sociable or something Mar 31 17:07:54 yeah, get some recreation in. it is good for mental health and productivity. Mar 31 17:08:49 * RP cleaned up the garage earlier (long overdue, I can see the workbench again!), playing with motorcycles tomorrow... Mar 31 17:12:08 i actually took up carpentry and small electronics (like, hand-soldering custom boards for little AVR chips) as things to help me Get Work Done. Mar 31 17:12:25 because the best way to solve a design problem is normally to think about it clearly for a bit, then *get away from the keyboard and do something else*. Mar 31 17:21:03 sociable is for strange people Mar 31 17:28:27 can confirm i did get the segfaults from the librsvg build, though, so when i'm next looking at it, i can look at it successfully-ish. Mar 31 19:36:18 <[Sno]> moto-timo: RP: I finished the prepare of "Perl on embedded devices" layer work and updated meta-cpan/meta-cpan and my local stuff around Mar 31 19:37:04 [Sno] great. I'll check it out. Mar 31 19:37:31 <[Sno]> but I'm completely drained now ;) Mar 31 19:37:57 <[Sno]> a few flash devices tomorrow, some program text and I'm done :D Mar 31 19:38:56 <[Sno]> the BBB is very fragile - I had to work complete last week to get it run in reasonable way (still no uboot-fw-utils support) Mar 31 21:18:44 JPEW: I'm pretty sure you got it, nice catch. Mar 31 21:57:56 confirmed, JPEW's observation was the thing, master branch now fixed. Mar 31 22:11:52 np. coredumpctl did most of the hard work ;) Apr 01 00:14:04 It's actually sorta weird to me that it didn't bite my test program, which called syscall() right away. Apr 01 00:14:42 I have no idea how that was actually working without the setup code. I don't think I have a wrapper on getpid(). Apr 01 00:39:11 I wonder if maybe glibc has a way to invoke syscall() in a way that pseudo can't trap Apr 01 00:41:19 hah, never mind, you said your program called syscall() right away. I should read better Apr 01 02:43:55 seebs still here? **** ENDING LOGGING AT Sun Apr 01 03:00:01 2018