toasterson : gist.github.com/neuroserve/ccae0f9f343d53ae744df62ec0f75e54 <- pstack

Oh, right..... Stripped debug symbols by default in linux.....

Got any output from the console we could look at?

nope - only "segmentation fault core dumped"

hmmm then it's most likely a xbps bug though

thats a illegal memory access

even if it is related to a syscall it looks like glibc is misusing a syscall assumption or the assumption changed

but I would have thought, that this would come up pretty fast - although I don't know wether that is a common upgrade path...

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

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?

pi version 20221225T144337Z

mdb: CTF data is missing for uberdata_t; using current platform's offset for uberdata.all_lwps: unknown object file name

uberdata_t is part of libc

So that means whatever the error is, it's going to be in glibc actually.

uberdata_t.all_lwps is a linked list of type ulwp_t.

Yeah mdb shows libc debugging loaded on the core

You're probably going to need to dig into glibc source code for this.

pthread seems to be related

That's all userland stuff and illumos isn't even involved at that point.

Yay

Redis logs specifically dump an error stating to file a bug report on github

Once you get to where glibc is making syscalls, that's where we get involved.

That is nice to know actually

does this mean anything to you?

actually

The core is coming from check-redis-rdb

sorry, redis-check-rdb, backwards

It's possible the redis database is corrupt?

mdb: couldn't find type uberdata_t: unknown object file name

Redis has been known to shit itself and ruin your database.

I suppose that is possible

mdb: couldn't read frame for thread 0x1 at b: no mapping for address

mdb: couldn't read frame for thread 0x5 at d640000000000000: no mapping for address

Thats basically everything

Execpt it does denote teh registers

I just wanted to be sure that the pi upgrade we did recently didn't introduce a bug

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 ]

That's outside of my expertise with the kernel.

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?

Sure

Or I can post it on slack if that is easier

Slack would be fine

posted in a DM