Crash report
We started seeing rediss 6.2.6 crashing and also causing data corruption after OS migrated from RHEL 9.4 to RHEL 9.5. Below is one of the call stack we got.
Core was generated by `/home/caas/current/caas/tools/Linux/redis/6.2.6.1/fedora/9/x86_64/bin/redis-ser'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 sdslen (s=0x0) at /workdir/redis/redis-6.2.6/src/sds.h:88
warning: 88/workdir/redis/redis-6.2.6/src/sds.h: No such file or directory
[Current thread is 1 (LWP 655496)]
(gdb)
(gdb) bt
#0 sdslen (s=0x0) at /workdir/redis/redis-6.2.6/src/sds.h:88
#1 dictSdsKeyCompare (privdata=<optimized out>, key1=0x7f3bb34784b3, key2=0x0) at server.c:1260
#2 0x0000000000436f05 in dictFind (d=0x7f3bba40b4e0, key=0x7f3bb34784b3) at dict.c:515
#3 0x000000000048a592 in logCurrentClient () at debug.c:1632
#4 0x000000000048d0cf in printCrashReport () at debug.c:1846
#5 sigsegvHandler (sig=11, info=0x7ffceccf01f0, secret=0x7ffceccf00c0) at debug.c:1831
#6 <signal handler called>
#7 sdslen (s=0x0) at /workdir/redis/redis-6.2.6/src/sds.h:88
#8 dictSdsKeyCompare (privdata=<optimized out>, key1=0x7f3bb34784b3, key2=0x0) at server.c:1260
#9 0x0000000000436f05 in dictFind (d=0x7f3bba40b540, key=0x7f3bb34784b3) at dict.c:515
#10 0x000000000045a621 in getExpire (db=db@entry=0x7f3bba525000, key=key@entry=0x7f3bb21fcc60) at db.c:1433
#11 0x000000000045b8ff in keyIsExpired (key=0x7f3bb21fcc60, db=0x7f3bba525000) at db.c:1486
#12 expireIfNeeded (db=0x7f3bba525000, key=0x7f3bb21fcc60) at db.c:1542
#13 0x000000000045b9a1 in lookupKeyReadWithFlags (db=0x7f3bba525000, key=0x7f3bb21fcc60, flags=flags@entry=0) at db.c:109
#14 0x000000000045ba58 in lookupKeyRead (key=<optimized out>, db=<optimized out>) at db.c:152
#15 lookupKeyReadOrReply (c=c@entry=0x7f3bb6e9bb80, key=<optimized out>, reply=0x7f3bba44a440) at db.c:178
#16 0x000000000046b334 in getGenericCommand (c=0x7f3bb6e9bb80) at t_string.c:288
#17 0x000000000043bd71 in call (c=c@entry=0x7f3bb6e9bb80, flags=flags@entry=15) at server.c:3721
#18 0x000000000043d89c in processCommand (c=c@entry=0x7f3bb6e9bb80) at server.c:4241
#19 0x000000000044ff63 in processCommandAndResetClient (c=0x7f3bb6e9bb80) at networking.c:2039
#20 processInputBuffer (c=0x7f3bb6e9bb80) at networking.c:2140
#21 0x00000000004e38e0 in callHandler (handler=<optimized out>, conn=0x7f3bb724cd20) at /workdir/redis/redis-6.2.6/src/connhelpers.h:79
#22 tlsHandleEvent (conn=0x7f3bb724cd20, mask=<optimized out>) at tls.c:634
#23 0x0000000000434dd2 in aeProcessEvents (eventLoop=eventLoop@entry=0x7f3bba4230f0, flags=flags@entry=27) at ae.c:427
#24 0x000000000043503d in aeMain (eventLoop=0x7f3bba4230f0) at ae.c:487
#25 0x0000000000431241 in main (argc=<optimized out>, argv=0x7ffceccf11d8) at [server.c:6401](url)
Additional information
- OS vision: RHEL 9.5
- Running redid in cluster mode
- Using lettuce client 6.3.1.RELEASE
Comment From: jayant21kumar
Adding more statk trace from the dump
0x00007f2d5603e96b in ?? ()
#1 0x000000000048aa8b in bugReportEnd (killViaSignal=1, sig=11) at debug.c:1880
#2 <signal handler called>
#3 sdslen (s=0x7f2c00707053 <error: Cannot access memory at address 0x7f2c00707053>) at /workdir/redis/redis-6.2.6/src/sds.h:88
#4 dictSdsKeyCompare (privdata=<optimized out>, key1=0x7f2d2606dd63, key2=0x7f2c00707053) at server.c:1260
#5 0x0000000000436f05 in dictFind (d=0x7f2d55c0b540, key=0x7f2d2606dd63) at dict.c:515
#6 0x000000000045a621 in getExpire (db=db@entry=0x7f2d55d25000, key=key@entry=0x7f2d32258bc0) at db.c:1433
#7 0x000000000045b8ff in keyIsExpired (key=0x7f2d32258bc0, db=0x7f2d55d25000) at db.c:1486
#8 expireIfNeeded (db=0x7f2d55d25000, key=0x7f2d32258bc0) at db.c:1542
#9 0x000000000045c4d2 in lookupKeyWriteWithFlags (flags=0, key=0x7f2d32258bc0, db=0x7f2d55d25000) at db.c:161
#10 lookupKeyWrite (db=0x7f2d55d25000, key=0x7f2d32258bc0) at db.c:166
#11 0x000000000046b5a8 in setGenericCommand (c=0x7f2d25f432c0, flags=5, key=0x7f2d32258bc0, val=0x7f2cc34131b8, expire=0x7f2ce54250c8, unit=0,
ok_reply=0x0, abort_reply=0x0) at t_string.c:97
#12 0x000000000046b774 in setCommand (c=0x7f2d25f432c0) at t_string.c:267
#13 0x000000000043bd71 in call (c=c@entry=0x7f2d25f432c0, flags=flags@entry=15) at server.c:3721
#14 0x000000000043d89c in processCommand (c=c@entry=0x7f2d25f432c0) at server.c:4241
#15 0x000000000044ff63 in processCommandAndResetClient (c=0x7f2d25f432c0) at networking.c:2039
#16 processInputBuffer (c=0x7f2d25f432c0) at networking.c:2140
#17 0x00000000004e38e0 in callHandler (handler=<optimized out>, conn=0x7f2d352ce8a0) at /workdir/redis/redis-6.2.6/src/connhelpers.h:79
#18 tlsHandleEvent (conn=0x7f2d352ce8a0, mask=<optimized out>) at tls.c:634
#19 0x0000000000434dd2 in aeProcessEvents (eventLoop=eventLoop@entry=0x7f2d55c230f0, flags=flags@entry=27) at ae.c:427
#20 0x000000000043503d in aeMain (eventLoop=0x7f2d55c230f0) at ae.c:487
#21 0x0000000000431241 in main (argc=<optimized out>, argv=0x7ffd2cbcb0f8) at server.c:6401
----------------------------------------------------------------------------------------
(gdb) bt
#0 0x00007fca6a83e96b in ?? ()
#1 0x000000000048aa8b in bugReportEnd (killViaSignal=1, sig=11) at debug.c:1880
#2 <signal handler called>
#3 0x00000000004c850d in sdslen (s=0x0) at /workdir/redis/redis-6.2.6/src/sds.h:88
#4 activeExpireCycleTryExpire (db=db@entry=0x7fca6a525000, now=1739929092535, de=<optimized out>, de=<optimized out>) at expire.c:58
#5 0x00000000004c8813 in activeExpireCycleTryExpire (now=1739929092535, de=<optimized out>, db=0x7fca6a525000) at expire.c:56
#6 activeExpireCycle (type=type@entry=0) at expire.c:261
#7 0x00000000004395f7 in databasesCron () at server.c:1858
#8 0x000000000043cc3a in serverCron (eventLoop=<optimized out>, id=<optimized out>, clientData=<optimized out>) at server.c:2135
#9 0x0000000000434c39 in processTimeEvents (eventLoop=0x7fca6a4230f0) at ae.c:318
#10 aeProcessEvents (eventLoop=eventLoop@entry=0x7fca6a4230f0, flags=flags@entry=27) at ae.c:457
#11 0x000000000043503d in aeMain (eventLoop=0x7fca6a4230f0) at ae.c:487
#12 0x0000000000431241 in main (argc=<optimized out>, argv=0x7fff70421868) at server.c:6401
on further analysis found lot of keys in dict have null pointers
Index 28: Found entry with key=0x0 at 0x7fca653a0028
Index 53: Found entry with key=0x0 at 0x7fca65451630
Index 120: Found entry with key=0x0 at 0x7fca65f41888
Index 122: Found entry with key=0x0 at 0x7fca65622560
Index 154: Found entry with key=0x0 at 0x7fca66a0b058
Index 171: Found entry with key=0x0 at 0x7fca65621018
Index 214: Found entry with key=0x0 at 0x7fca656289a0
Index 244: Found entry with key=0x0 at 0x7fca65451270
Index 267: Found entry with key=0x0 at 0x7fca656227d0
Index 336: Found entry with key=0x0 at 0x7fca65628880
Index 366: Found entry with key=0x0 at 0x7fca6539e000
Index 369: Found entry with key=0x0 at 0x7fca6606e418
Index 373: Found entry with key=0x0 at 0x7fca65621a80
Index 395: Found entry with key=0x0 at 0x7fca65f41258
Index 466: Found entry with key=0x0 at 0x7fca6606e3b8
Index 479: Found entry with key=0x0 at 0x7fca65f43eb0
Index 488: Found entry with key=0x0 at 0x7fca6539f4a0
Index 491: Found entry with key=0x0 at 0x7fca65e69370
Index 521: Found entry with key=0x0 at 0x7fca6606e5e0
Index 540: Found entry with key=0x0 at 0x7fca65f41828
Index 600: Found entry with key=0x0 at 0x7fca65f43d30
Index 626: Found entry with key=0x0 at 0x7fca6606dc68
Index 645: Found entry with key=0x0 at 0x7fca65628f58
Index 730: Found entry with key=0x0 at 0x7fca65452920
Index 777: Found entry with key=0x0 at 0x7fca6606ed78
Index 797: Found entry with key=0x0 at 0x7fca652f9978
Index 805: Found entry with key=0x0 at 0x7fca65628a78
Index 829: Found entry with key=0x0 at 0x7fca6539e498
Index 841: Found entry with key=0x0 at 0x7fca65e67840
Index 855: Found entry with key=0x0 at 0x7fca65e69f40
Index 857: Found entry with key=0x0 at 0x7fca652f98e8
Index 885: Found entry with key=0x0 at 0x7fca65e69e50
Index 899: Found entry with key=0x0 at 0x7fca652f9c18
Index 910: Found entry with key=0x0 at 0x7fca65f420c8
Index 929: Found entry with key=0x0 at 0x7fca6606e8f8
Index 934: Found entry with key=0x0 at 0x7fca65e67438
Index 1002: Found entry with key=0x0 at 0x7fca65f41570
Index 1040: Found entry with key=0x0 at 0x7fca65f418b8
Index 1070: Found entry with key=0x0 at 0x7fca65e67168
Index 1089: Found entry with key=0x0 at 0x7fca65f41e40
Index 1133: Found entry with key=0x0 at 0x7fca653a02f8
Index 1148: Found entry with key=0x0 at 0x7fca654520e0
Index 1165: Found entry with key=0x0 at 0x7fca66a0b8e0
--Type <RET> for more, q to quit, c to continue without paging--c
Index 1236: Found entry with key=0x0 at 0x7fca6606d9b0
Index 1280: Found entry with key=0x0 at 0x7fca65f431a8
Index 1311: Found entry with key=0x0 at 0x7fca6606ed60
Index 1318: Found entry with key=0x0 at 0x7fca65451d20
Index 1370: Found entry with key=0x0 at 0x7fca65f42950
Index 1374: Found entry with key=0x0 at 0x7fca65f43e68
Index 1390: Found entry with key=0x0 at 0x7fca653a0010
Index 1410: Found entry with key=0x0 at 0x7fca65451ab0
Index 1419: Found entry with key=0x0 at 0x7fca65621438
Index 1425: Found entry with key=0x0 at 0x7fca6606e6a0
...
...
...
-----------------------------------------------------------------------------------------------------
(gdb) bt
#0 0x00007f1c9688826d in pthread_cancel@GLIBC_2.2.5 () from /lib64/libc.so.6
#1 0x00000000004a1b35 in bioKillThreads () at bio.c:298
#2 0x000000000048a4b8 in killThreads () at debug.c:1726
#3 0x000000000048a4b8 in doFastMemoryTest () at debug.c:1735
#4 0x000000000048a4b8 in printCrashReport () at debug.c:1852
#5 0x000000000048a4b8 in sigsegvHandler (sig=11, info=0x7ffeb75e3700, secret=0x7ffeb75e3700) at debug.c:1831
#6 <signal handler called>
#7 0x00007f1c9688826d in pthread_cancel@GLIBC_2.2.5 () from /lib64/libc.so.6
#8 0x00000000004a1b35 in bioKillThreads () at bio.c:298
#9 0x000000000048a4b8 in killThreads () at debug.c:1726
#10 0x000000000048a4b8 in doFastMemoryTest () at debug.c:1735
#11 0x000000000048a4b8 in printCrashReport () at debug.c:1852
#12 _serverPanic (file=file@entry=0x57ffdd "server.c", line=line@entry=5967,
msg=msg@entry=0x57c4c0 "Redis aborting for OUT OF MEMORY. Allocating %zu bytes!") at debug.c:1003
#13 0x0000000000438b97 in redisOutOfMemoryHandler (allocation_size=32651097298436093) at server.c:5967
#14 0x00000000004452a9 in zmalloc (size=32651097298436093) at zmalloc.c:120
#15 0x00000000004646ce in rdbSaveLzfStringObject (len=32651097298436096, s=0x7f1c82c10000 "000010y3Asr",
len=len@entry=32651097298436096) at rdb.c:367
#16 0x000000000046505d in rdbSaveLzfStringObject (len=32651097298436096, s=0x7f1c82c10000 "000010y3Asr", rdb=0x7ffeb75e48f0) at rdb.c:365
#17 rdbSaveRawString (rdb=0x7ffeb75e48f0, s=0x7f1c82c10000 "000010y3Asr", len=32651097298436096) at rdb.c:448
#18 0x00000000004655fd in rdbSaveKeyValuePair (rdb=rdb@entry=0x7ffeb75e48f0, key=key@entry=0x7ffeb75e4810,
expiretime=<optimized out>) at rdb.c:1131
#19 0x0000000000466d7c in rdbSaveRio (rdb=rdb@entry=0x7ffeb75e48f0, error=error@entry=0x0, rdbflags=rdbflags@entry=0,
rsi=rsi@entry=0x7ffeb75e49a0) at rdb.c:1342
#20 0x00000000004715a in rdbSaveRioWithMemoryStats (rdb=rdb@entry=0x7ffeb75e48f0, error=error@entry=0x0,
rsi=rsi@entry=0x7ffeb75e49a0) at rdb.c:2917
#21 0x0000000000464b3a in rdbSaveToSlavesSockets (rs=0x7ffeb75e49a0) at replication.c:661
#22 0x000000000045e5c6 in call (c=c@entry=0x7f1a9abf8c0, flags=flags@entry=15) at server.c:3721
#23 0x0000000000464963 in processCommand (c=0x7f1a9abf8c0) at server.c:4241
#24 0x0000000000465c3e in processInputBuffer (c=0x7f1a9ab2f8c0) at networking.c:2039
#25 0x000000000041f98 in athandler (conn=0x7f1a50b5bd00) at /workdir/redis-6.2.6/src/connhelpers.h:79
#26 connSocketEventHandler (el=<optimized out>, fd=<optimized out>, clientData=0x7f1a50b5bd00, mask=<optimized out>) at connection.c:295
#27 0x000000000041f3a in aeMain (eventLoop=0x7f1c964230f0) at ae.c:427
#28 0x000000000041312 in main (argc=<optimized out>, argv=<optimized out>) at server.c:6401
--------------------------------------------------------------------------------------------------------------------
(gdb) bt
#0 0x00007f93112826d in pthread_cancel@GLIBC_2.2.5 () from /lib64/libc.so.6
#1 0x0000000000404b35 in bioKillThreads () at bio.c:298
#2 0x00000000004a86a in killThreads () at debug.c:1726
#3 0x00000000004a8a8 in doFastMemoryTest () at debug.c:1735
#4 0x000000000048d0d9 in printCrashReport () at debug.c:1852
#5 sigsegvHandler (sig=11, info=0x7ffd0af1360, secret=0x7ffd0af135c0) at debug.c:1831
#6 <signal handler called>
#7 sdslen (s=0x0) at /workdir/redis/redis-6.2.6/src/sds.h:88
#8 rdbSaveStringObject (rdb=0x7ffd0af14450, obj=<optimized out>) at rdb.c:491
#9 0x000000000046061 in rdbSaveKeyValuePair (rdb=rdb@entry=0x7ffd0af14450, key=key@entry=0x7ffd0af14450,
expiretime=<optimized out>) at rdb.c:1144
#10 0x000000000046d7c in rdbSaveRio (rdb=rdb@entry=0x7ffd0af14450, error=error@entry=0x0, rdbflags=rdbflags@entry=0,
rsi=rsi@entry=0x7ffd0af14500) at rdb.c:1342
#11 0x000000000046715a in rdbSaveRioWithEOFMark (rdb=rdb@entry=0x7ffd0af14450, error=error@entry=0x0,
rsi=rsi@entry=0x7ffd0af14500) at rdb.c:2917
#12 0x0000000000464a3b in rdbSaveToSlavesSockets () at replication.c:661
#13 0x000000000043bd7l in call (c=c@entry=0x7f9070fa7180, flags=flags@entry=15) at server.c:3721
#14 0x000000000044f63 in processCommandAndResetClient (c=0x7f9070fa7180) at server.c:4241
#15 processInputBuffer (c=0x7f9070fa7180) at networking.c:2039
#16 0x00000000004e1f98 in callHandler (el=el@entry=0x7f91e7d619c0) at /workdir/redis/
connection.c:295
#17 0x0000000000412d3 in aeProcessEvents (eventLoop=0x7f9310e230f0, flags=flags@entry=27) at ae.c:427
#18 0x000000000041321 in aeMain (eventLoop=0x7f9310e230f0) at ae.c:487
#19 0x0000000000431421 in main (argc=<optimized out>, argv=<optimized out>) at server.c:6401
Comment From: oranagra
this smells like a memory corruption to me.
#8 dictSdsKeyCompare (privdata=<optimized out>, key1=0x7f3bb34784b3, key2=0x0) at server.c:1260
this means the key that was stored in the db dict is NULL. which is very odd.
#17 rdbSaveRawString (rdb=0x7ffeb75e48f0, s=0x7f1c82c10000 "000010y3Asr", len=32651097298436096) at rdb.c:448
trying to save a string with insane length.
however, the line numbers don't seem to match redis 6.2.6, are you sure this is an unmodified version of the code base?
if this is a memory corruption, maybe it's a result of a corrupt data, maybe the sanitize-dump-payload can help find find something.
Comment From: jayant21kumar
We received a dump that was relatively small and were investigating all the keys that were null. After loading the dump into GDB, we inspected the memory using the following command: x/100xb ADDR. We observed block of memory is all set to value 0 which is getting pointed by the "table"
Below is one example of what we observed. (gdb)bt
0 0x00007fca6a83e96b in ?? ()
1 0x000000000048aa8b in bugReportEnd (killViaSignal=1, sig=11) at debug.c:1880
2
3 0x00000000004c850d in sdslen (s=0x0) at /workdir/redis/redis-6.2.6/src/sds.h:88
4 activeExpireCycleTryExpire (db=db@entry=0x7fca6a525000, now=1739929092535, de=, de=) at expire.c:58
5 0x00000000004c8813 in activeExpireCycleTryExpire (now=1739929092535, de=, db=0x7fca6a525000) at expire.c:56
6 activeExpireCycle (type=type@entry=0) at expire.c:261
7 0x00000000004395f7 in databasesCron () at server.c:1858
8 0x000000000043cc3a in serverCron (eventLoop=, id=, clientData=) at server.c:2135
9 0x0000000000434c39 in processTimeEvents (eventLoop=0x7fca6a4230f0) at ae.c:318
10 aeProcessEvents (eventLoop=eventLoop@entry=0x7fca6a4230f0, flags=flags@entry=27) at ae.c:457
11 0x000000000043503d in aeMain (eventLoop=0x7fca6a4230f0) at ae.c:487
12 0x0000000000431241 in main (argc=, argv=0x7fff70421868) at server.c:6401
(gdb) set $db = (redisDb )0x7fca6a525000 (gdb) print $db $9 = {dict = 0x7fca6a40b4e0, expires = 0x7fca6a40b540, blocking_keys = 0x7fca6a40b5a0, ready_keys = 0x7fca6a40b600, watched_keys = 0x7fca6a40b660, id = 0, avg_ttl = 165620707, expires_cursor = 169360, defrag_later = 0x7fca6a40f450} (gdb) set $dict = (dict )0x7fca6a40b4e0 (gdb) set $ht = $dict.ht[0] (gdb) print $ht $1 = {table = 0x7fca650e8780, size = 32768, sizemask = 32767, used = 30312} (gdb) set $table = $ht.table (gdb) print $table[28] $3 = {key = 0x7fca637effab, v = {val = 0x7fca6443b550, u64 = 140507242280272, s64 = 140507242280272, d = 6.9419801402575088e-310}, next = 0x7fca653a0028} (gdb) print $table[28]->next $4 = {key = 0x0, v = {val = 0x0, u64 = 0, s64 = 0, d = 0}, next = 0x0} (gdb) print $table[28]->next $5 = (struct dictEntry ) 0x7fca653a0028
Below is the content of the address (gdb) x/100xb 0x7fca653a0000 0x7fca653a0000: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0008: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0010: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0018: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0020: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0028: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0030: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0038: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0040: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0048: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0050: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0058: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0060: 0x00 0x00 0x00 0x00
(gdb) x/100xb 0x7fca653a0fe0 0x7fca653a0fe0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0fe8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0ff0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a0ff8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x7fca653a1000: 0x5f 0x6c 0x01 0x63 0x6f 0x72 0x65 0x2e 0x7fca653a1008: 0x61 0x70 0x35 0x34 0x3a 0x4d 0x72 0x75 0x7fca653a1010: 0x41 0x66 0x66 0x69 0x6e 0x69 0x74 0x79 0x7fca653a1018: 0x43 0x61 0x63 0x68 0x65 0x3a 0x3a 0x3a 0x7fca653a1020: 0x32 0x35 0x34 0x3a 0x31 0x37 0x30 0x2d 0x7fca653a1028: 0x4d 0x72 0x75 0x41 0x66 0x66 0x69 0x6e 0x7fca653a1030: 0x69 0x74 0x79 0x43 0x61 0x63 0x68 0x65 0x7fca653a1038: 0x30 0x30 0x44 0x32 0x76 0x30 0x30 0x30 0x7fca653a1040: 0x30 0x30 0x31 0x67
We see that few memory block of size 4KB is all 0x0. In this case all the value is 0 till address 0x7fca653a1000. We saw similar pattern for below address range as well 0x7fca66071000 - 0x7fca66073000 0x7fca6606d000 - 0x7fca6606f000
Looks like whole page which is suppose to contain valid information is getting reset and now contains value 0x0.
Meanwhile we tried running Redis 6.2.6 in RHEL 9.5 with glibc library present in RHEL 9.4 but that also didn't help.
We are looking at enabling sanitize-dump-payload but my guess is corruption is happening after the value is stored. So probably will not give much information.
Also we download the Redis source zip file and compile with TLS and jemalloc.
Comment From: oranagra
Also we download the Redis source zip file and compile with TLS and jemalloc.
where did you get the previous redis from? YUM?
maybe it's a good idea to try upgrading to 6.2.16, and / or try building it with -fsanitize=address
Comment From: jayant21kumar
The same way..download the zip file and compile it. Binary gets bundled as part of our deployment.
Comment From: moazam1
@jayant21kumar are you still having same issue? Was it related to your hardware?