08:31:09 <neuroserve> toasterson : https://gist.github.com/neuroserve/ccae0f9f343d53ae744df62ec0f75e54 <- pstack
10:16:14 <toasterson> Oh, right..... Stripped debug symbols by default in linux.....
10:16:26 <toasterson> Got any output from the console we could look at?
10:22:11 <neuroserve> nope - only "segmentation fault core dumped"
10:22:52 <toasterson> hmmm then it's most likely a xbps bug though
10:23:08 <toasterson> thats a illegal memory access
10:23:41 <toasterson> even if it is related to a syscall it looks like glibc is misusing a syscall assumption or the assumption changed
10:25:51 <neuroserve> but I would have thought, that this would come up pretty fast - although I don't know wether that is a common upgrade path...
10:26:56 <toasterson> which is why it's sad we can't look at the stack and see if there is a C bug in the function iside glibc
20:41:32 <barfield> I have a customer running redis in an LX branded Ubuntu zone. Redis is crashing complaining about memory (even though memory tests pass). I noticed a couple of cores in the zones/UUID/cores folder called core.redis.X I loaded one up in MDB and simply ran ::stacks. Output is complaining about uberdata_t with some erorrs. Wondering if anyone might point me in the right direction with some more data? 
20:42:16 <barfield> pi version 20221225T144337Z
20:42:47 <barfield> mdb: CTF data is missing for uberdata_t; using current platform's offset for uberdata.all_lwps: unknown object file name
20:46:43 <bahamat> uberdata_t is part of libc
20:47:09 <bahamat> So that means whatever the error is, it's going to be in glibc actually.
20:48:50 <bahamat> uberdata_t.all_lwps is a linked list of type ulwp_t.
20:49:09 <barfield> Yeah mdb shows libc debugging loaded on the core
20:49:39 <bahamat> You're probably going to need to dig into glibc source code for this.
20:49:41 <barfield> pthread seems to be related
20:49:58 <bahamat> That's all userland stuff and illumos isn't even involved at that point.
20:49:59 <barfield> Yay
20:50:15 <barfield> Redis logs specifically dump an error stating to file a bug report on github
20:50:21 <bahamat> Once you get to where glibc is making syscalls, that's where we get involved.
20:50:42 <barfield> That is nice to know actually
20:51:00 <barfield> does this mean anything to you?
20:51:20 <barfield> actually
20:51:27 <barfield> The core is coming from check-redis-rdb
20:51:43 <barfield> sorry, redis-check-rdb, backwards
20:52:03 <bahamat> It's possible the redis database is corrupt?
20:52:11 <barfield> mdb: couldn't find type uberdata_t: unknown object file name
20:52:16 <bahamat> Redis has been known to shit itself and ruin your database.
20:52:29 <barfield> I suppose that is possible
20:52:47 <barfield> mdb: couldn't read frame for thread 0x1 at b: no mapping for address
20:52:54 <barfield> mdb: couldn't read frame for thread 0x5 at d640000000000000: no mapping for address
20:52:59 <barfield> Thats basically everything 
20:53:05 <barfield> Execpt it does denote teh registers
20:53:50 <barfield> I just wanted to be sure that the pi upgrade we did recently didn't introduce a bug
20:55:02 <barfield> Also its not like I'm a pro core debugger, but here are the modules: Loading modules: [ libc.so.1 ld.so.1 libc.so.6 ]
20:56:14 <bahamat> That's outside of my expertise with the kernel.
20:59:17 <barfield> I would send you the redis error but hate to poste it on pastebin just in case. Could I email you just to see if anything jumps out and bites you? 
20:59:58 <bahamat> Sure
21:00:16 <barfield> Or I can post it on slack if that is easier
21:01:17 <bahamat> Slack would be fine
21:08:06 <barfield> posted in a DM