During debugging kodi with memset script I run into a SIGSEGV on an older i7 Intel CPU with the flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts md_clear flush_l1d the debugger gdb shows #0 __memset_sse2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:322 (gdb) list 317 #endif 318 /* Align dst for loop. */ 319 andq $(VEC_SIZE * -2), %LOOP_REG 320 .p2align 4 321 L(loop): 322 VMOVA %VEC(0), LOOP_4X_OFFSET(%LOOP_REG) 323 VMOVA %VEC(0), (VEC_SIZE + LOOP_4X_OFFSET)(%LOOP_REG) 324 VMOVA %VEC(0), (VEC_SIZE * 2 + LOOP_4X_OFFSET)(%LOOP_REG) 325 VMOVA %VEC(0), (VEC_SIZE * 3 + LOOP_4X_OFFSET)(%LOOP_REG) 326 subq $-(VEC_SIZE * 4), %LOOP_REG
Don't know if Component is correct set
Could you try to reconstruct the arguments to memset? What is your exact glibc version (distribution build)? Is it unpatched glibc-2.35? Thanks.
Are there any steps for reproduction?
Created attachment 14197 [details] Robust tests glibc 2.35 Unable to reproduce with this on GLIBC 2.35. Any hints about the size / ptr?
(In reply to Noah Goldstein from comment #4) > Created attachment 14197 [details] > Robust tests glibc 2.35 > Some patch essentially also runs fine on master. Sorry, but need more info to figure this out. > Unable to reproduce with this on GLIBC 2.35. > > Any hints about the size / ptr?
Please set break point at __memset_sse2_unaligned_erms and print out $rdx/$rdi. We need the last pair of $rdx and $rdi before crash.
(In reply to H.J. Lu from comment #6) > Please set break point at __memset_sse2_unaligned_erms and print out > $rdx/$rdi. > We need the last pair of $rdx and $rdi before crash. Can you also set a breakpoint as `__memset_sse2_unaligned`. Intuitively you are going through that as the tests I ran should cover all values / alignments that go to the loop (think for the erms version we would see a segfault at the `rep stosb`).
(In reply to Florian Weimer from comment #2) > Could you try to reconstruct the arguments to memset? What is your exact > glibc version (distribution build)? Is it unpatched glibc-2.35? Thanks. It is likly not an unpatched version of glibc here at openSUSE, maintainer is Anreas Schwab and you'll find the source tree at https://build.opensuse.org/package/show/Base:System/glibc
(In reply to Noah Goldstein from comment #3) > Are there any steps for reproduction? I've tried the memusage script of glibc utils to debug memory consumption of kodi Matric 19.4, this works like this: export LD_PRELOAD=/lib64/libmemusage.so export MEMUSAGE_OUTPUT=/dev/null export MEMUSAGE_TRACE_MMAP=yes but this make gdb a memory huge eating all physical RAM. Therefore I tried to set the environment in gdb its self: gdb --args /usr/lib64/kodi/kodi.bin [...] (gdb) set environment LD_PRELOAD /lib64/libmemusage.so (gdb) set environment MEMUSAGE_OUTPUT /dev/null (gdb) set environment MEMUSAGE_TRACE_MMAP yes (gdb) run Starting program: /usr/lib64/kodi/kodi.bin Program terminated with signal SIGPROF, Profiling timer expired. The program no longer exists. (gdb) br memset Breakpoint 1 at 0x705f80 (2 locations) (gdb) run Starting program: /usr/lib64/kodi/kodi.bin Breakpoint 1, memset () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:125 125 ENTRY (MEMSET_SYMBOL (__memset, unaligned)) (gdb) list 120 cmp %RDX_LP, %RCX_LP 121 jb HIDDEN_JUMPTARGET (__chk_fail) 122 END_CHK (MEMSET_CHK_SYMBOL (__memset_chk, unaligned)) 123 #endif 124 125 ENTRY (MEMSET_SYMBOL (__memset, unaligned)) 126 MEMSET_VDUP_TO_VEC0_AND_SET_RETURN (%esi, %rdi) 127 # ifdef __ILP32__ 128 /* Clear the upper 32 bits. */ 129 mov %edx, %edx (gdb) print $rdi $1 = 140737353858200 (gdb) print $rdx $2 = 36 (gdb) print $esi $3 = 0
(In reply to Noah Goldstein from comment #7) > (In reply to H.J. Lu from comment #6) > > Please set break point at __memset_sse2_unaligned_erms and print out > > $rdx/$rdi. > > We need the last pair of $rdx and $rdi before crash. > > Can you also set a breakpoint as `__memset_sse2_unaligned`. Intuitively you > are going through that as the tests I ran should cover all values / > alignments that go to the loop (think for the erms version we would see a > segfault at the `rep stosb`). Setting a breakpoint on menset works whereas for __memset_sse2_unaligned I see only Program terminated with signal SIGPROF, Profiling timer expired. The program no longer exists.
Please use LD_AUDIT to print out RDX and RDI for memset.
(In reply to Dr. Werner Fink from comment #9) > (In reply to Noah Goldstein from comment #3) > > Are there any steps for reproduction? > > I've tried the memusage script of glibc utils to debug memory consumption of > kodi Matric 19.4, this works like this: > > export LD_PRELOAD=/lib64/libmemusage.so > export MEMUSAGE_OUTPUT=/dev/null > export MEMUSAGE_TRACE_MMAP=yes > > but this make gdb a memory huge eating all physical RAM. > > Therefore I tried to set the environment in gdb its self: > > gdb --args /usr/lib64/kodi/kodi.bin > [...] > (gdb) set environment LD_PRELOAD /lib64/libmemusage.so > (gdb) set environment MEMUSAGE_OUTPUT /dev/null > (gdb) set environment MEMUSAGE_TRACE_MMAP yes > (gdb) run > Starting program: /usr/lib64/kodi/kodi.bin > > Program terminated with signal SIGPROF, Profiling timer expired. > The program no longer exists. > (gdb) br memset > Breakpoint 1 at 0x705f80 (2 locations) > (gdb) run > Starting program: /usr/lib64/kodi/kodi.bin > > Breakpoint 1, memset () at > ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:125 > 125 ENTRY (MEMSET_SYMBOL (__memset, unaligned)) > (gdb) list > 120 cmp %RDX_LP, %RCX_LP > 121 jb HIDDEN_JUMPTARGET (__chk_fail) > 122 END_CHK (MEMSET_CHK_SYMBOL (__memset_chk, unaligned)) > 123 #endif > 124 > 125 ENTRY (MEMSET_SYMBOL (__memset, unaligned)) > 126 MEMSET_VDUP_TO_VEC0_AND_SET_RETURN (%esi, %rdi) > 127 # ifdef __ILP32__ > 128 /* Clear the upper 32 bits. */ > 129 mov %edx, %edx > > (gdb) print $rdi > $1 = 140737353858200 > (gdb) print $rdx > $2 = 36 > (gdb) print $esi > $3 = 0 I don't see how those values could segfault, Are you sure `rdi` points to valid memory?
(In reply to H.J. Lu from comment #11) > Please use LD_AUDIT to print out RDX and RDI for memset. ... I've tried that with exporting LD_AUDIT=/lib64/libmemusage.so:/lib64/libc.so.6 in gdb (without `=' and `set environment`) as well as with preloading /lib64/libmemusage.so but this shows (gdb) set environment LD_AUDIT /lib64/libmemusage.so:/lib64/libc.so.6 (gdb) set environment LD_PRELOAD /lib64/libmemusage.so (gdb) set environment MEMUSAGE_OUTPUT /dev/null (gdb) set environment MEMUSAGE_TRACE_MMAP yes (gdb) run Starting program: /usr/lib64/kodi/kodi.bin During startup program terminated with signal SIGSEGV, Segmentation fault. using a core dump shows with coredumpctl Message: Process 2029 (kodi.bin) of user 223 dumped core. Module /usr/lib64/kodi/kodi.bin with build-id e1ff57cc18fdbfb94f9c868d0390ae072a644e1a Module /usr/lib64/libc.so.6 with build-id 712c0cad2c922965a1c0d127ae86a118675ff13a Module /usr/lib64/libmemusage.so with build-id 1e3a860bf330a7dbf351bdf99fc7d54bdf78338e Module /usr/lib64/ld-linux-x86-64.so.2 with build-id 97b21d01a6af70cd365d50707e35559701f446ac Module linux-vdso.so.1 with build-id 8afe55b49ea313a498cf2943d1ed322dd2573036 Stack trace of thread 2029: #0 0x00007fb5b14a32fc ___dlsym (/usr/lib64/libc.so.6 + 0xa32fc) #1 0x00007fb5b17fab31 me (/usr/lib64/libmemusage.so + 0x1b31) #2 0x00007fb5b199418e call_init (/usr/lib64/ld-linux-x86-64.so.2 + 0x818e) #3 0x00007fb5b199428c _dl_init (/usr/lib64/ld-linux-x86-64.so.2 + 0x828c) #4 0x00007fb5b19a9df8 _dl_catch_exception (/usr/lib64/ld-linux-x86-64.so.2 + 0x1ddf8) #5 0x00007fb5b199b5e6 dl_open_worker (/usr/lib64/ld-linux-x86-64.so.2 + 0xf5e6) #6 0x00007fb5b19a9db9 _dl_catch_exception (/usr/lib64/ld-linux-x86-64.so.2 + 0x1ddb9) #7 0x00007fb5b199b9cc _dl_open (/usr/lib64/ld-linux-x86-64.so.2 + 0xf9cc) #8 0x00007fb5b19acc2e dlmopen_doit (/usr/lib64/ld-linux-x86-64.so.2 + 0x20c2e) #9 0x00007fb5b19a9db9 _dl_catch_exception (/usr/lib64/ld-linux-x86-64.so.2 + 0x1ddb9) #10 0x00007fb5b19a9e63 _dl_catch_error (/usr/lib64/ld-linux-x86-64.so.2 + 0x1de63) #11 0x00007fb5b19b0332 load_audit_module (/usr/lib64/ld-linux-x86-64.so.2 + 0x24332) #12 0x00007fb5b19abf7f _dl_sysdep_start (/usr/lib64/ld-linux-x86-64.so.2 + 0x1ff7f) #13 0x00007fb5b19ade9e _dl_start_final (/usr/lib64/ld-linux-x86-64.so.2 + 0x21e9e) #14 0x00007fb5b19acb98 _start (/usr/lib64/ld-linux-x86-64.so.2 + 0x20b98) ELF object binary architecture: AMD x86-64 but gdb shows with this core Reading symbols from /usr/lib64/kodi/kodi.bin... Reading symbols from /usr/lib/debug/usr/lib64/kodi/kodi.bin-19.4-2.14.x86_64.debug... [New LWP 2029] Core was generated by `/usr/lib64/kodi/kodi.bin'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fb5b14a32fc in ?? () (gdb) bt #0 0x00007fb5b14a32fc in ?? () #1 0x0000000000000007 in ?? () #2 0x00007fb5b1458872 in ?? () #3 0x00007fb5b1988440 in ?? () #4 0x00007fb5b17fdce0 in ?? () #5 0x0000000000000001 in ?? () #6 0xce7c2412b4499900 in ?? () #7 0x00007ffd4fd8bc48 in ?? () #8 0x0000000000000000 in ?? () (gdb) quit
(In reply to Noah Goldstein from comment #12) > (In reply to Dr. Werner Fink from comment #9) > > (gdb) print $rdi > > $1 = 140737353858200 > > (gdb) print $rdx > > $2 = 36 > > (gdb) print $esi > > $3 = 0 > > I don't see how those values could segfault, > > Are you sure `rdi` points to valid memory? No I'm not, I only want to debug the memory usage of kodi with the help of libmemusage.so and run into this problem. Meanwhile I've tried the heaptrack tool to debug the memory usage of kodi (https://userbase.kde.org/Heaptrack). This tool is also preloading a library libheaptrack_preload.so or libheaptrack_inject.so. As you can see at https://sourceware.org/bugzilla/show_bug.cgi?id=29327 there is also a different crash with memusage script but with dolphin with a fully different stack.
Created attachment 14202 [details] LD_AUDIT example Here is an example for LD_AUDIT: [hjl@gnu-cfl-1 audit-memset]$ make LD_AUDIT=./auditmod.so ./foo version: 2 memset: dst=0x601060, src=0x3, len=33 pltenter: memset: dst=0x601060, src=3, len=33 [hjl@gnu-cfl-1 audit-memset]$ We need arguments of the last memset call.
Created attachment 14205 [details] audit.log (In reply to H.J. Lu from comment #15) > Created attachment 14202 [details] > LD_AUDIT example > > Here is an example for LD_AUDIT: > > [hjl@gnu-cfl-1 audit-memset]$ make > LD_AUDIT=./auditmod.so ./foo > version: 2 > memset: dst=0x601060, src=0x3, len=33 > pltenter: memset: dst=0x601060, src=3, len=33 > [hjl@gnu-cfl-1 audit-memset]$ > > We need arguments of the last memset call. Lets try /kodi> ( setenv LD_AUDIT ./auditmod.so ; ./foo ) version: 2 memset: dst=0x404060, src=0x3, len=33 pltenter: memset: dst=0x404060, src=3, len=33 yep /kodi> ( setenv LD_AUDIT ./auditmod.so ; setenv LD_PRELOAD /lib64/libmemusage.so ; setenv MEMUSAGE_OUTPUT /dev/null ; setenv MEMUSAGE_TRACE_MMAP yes ; /usr/lib64/kodi/kodi.bin ) version: 2 Segmentation fault (core dumped) libmemusage does not allow ... then without /kodi> ( setenv LD_AUDIT ./auditmod.so ; /usr/lib64/kodi/kodi.bin ) | & tee audit.log ... that is a longer list, see attachment
Created attachment 14206 [details] coredumpctl.log The output of coredumpctl for the core of the run with kodi.bin kodi> sudo coredumpctl dump -o /tmp/core 2616 | & tee coredumpctl.log the gdb shows only (gdb) bt #0 0x00007fefb76c5240 in ()
Could it be that auditmod.so can not be combined with /lib64/libmemusage.so? Even if so, the crash of kodi.bin only happens with preloading libmemusage.so
The last memset call is dst=0x7ff43008ed78, src=0, len=8. It should never reach the loop.
(In reply to Dr. Werner Fink from comment #16) > Created attachment 14205 [details] > audit.log > > (In reply to H.J. Lu from comment #15) > > Created attachment 14202 [details] > > LD_AUDIT example > > > > Here is an example for LD_AUDIT: > > > > [hjl@gnu-cfl-1 audit-memset]$ make > > LD_AUDIT=./auditmod.so ./foo > > version: 2 > > memset: dst=0x601060, src=0x3, len=33 > > pltenter: memset: dst=0x601060, src=3, len=33 > > [hjl@gnu-cfl-1 audit-memset]$ > > > > We need arguments of the last memset call. > > Lets try > > /kodi> ( setenv LD_AUDIT ./auditmod.so ; ./foo ) > version: 2 > memset: dst=0x404060, src=0x3, len=33 > pltenter: memset: dst=0x404060, src=3, len=33 > > yep > > /kodi> ( setenv LD_AUDIT ./auditmod.so ; setenv LD_PRELOAD > /lib64/libmemusage.so ; setenv MEMUSAGE_OUTPUT /dev/null ; setenv > MEMUSAGE_TRACE_MMAP yes ; /usr/lib64/kodi/kodi.bin ) > version: 2 > Segmentation fault (core dumped) > > libmemusage does not allow ... then without > > /kodi> ( setenv LD_AUDIT ./auditmod.so ; /usr/lib64/kodi/kodi.bin ) | & > tee audit.log > > ... that is a longer list, see attachment We need the audit.log from crash.
(In reply to H.J. Lu from comment #20) > (In reply to Dr. Werner Fink from comment #16) > > Created attachment 14205 [details] > > audit.log [...] > > We need the audit.log from crash. Yes ... this should be https://sourceware.org/bugzilla/attachment.cgi?id=14205
(In reply to Dr. Werner Fink from comment #21) > (In reply to H.J. Lu from comment #20) > > (In reply to Dr. Werner Fink from comment #16) > > > Created attachment 14205 [details] > > > audit.log > > [...] > > > > > We need the audit.log from crash. > > Yes ... this should be > https://sourceware.org/bugzilla/attachment.cgi?id=14205 But your command was /kodi> ( setenv LD_AUDIT ./auditmod.so ; /usr/lib64/kodi/kodi.bin ) | & tee audit.log and it didn't crash.
(In reply to H.J. Lu from comment #22) > (In reply to Dr. Werner Fink from comment #21) > > (In reply to H.J. Lu from comment #20) > > > (In reply to Dr. Werner Fink from comment #16) > > > > Created attachment 14205 [details] > > > > audit.log > > > > [...] > > > > > > > > We need the audit.log from crash. > > > > Yes ... this should be > > https://sourceware.org/bugzilla/attachment.cgi?id=14205 > > But your command was > > /kodi> ( setenv LD_AUDIT ./auditmod.so ; /usr/lib64/kodi/kodi.bin ) | & tee > audit.log > > and it didn't crash. Likewise for: pltenter: memset: dst=0x7ff43008ed78, src=0, len=8 I don't see this would segfault if `dst` has write permissions.
Created attachment 14209 [details] dumpctl.log (In reply to Noah Goldstein from comment #23) > (In reply to H.J. Lu from comment #22) > > (In reply to Dr. Werner Fink from comment #21) > > > (In reply to H.J. Lu from comment #20) > > > > (In reply to Dr. Werner Fink from comment #16) > > > > > Created attachment 14205 [details] > > > > > audit.log > > > > > > [...] > > > > > > > > > > > We need the audit.log from crash. > > > > > > Yes ... this should be > > > https://sourceware.org/bugzilla/attachment.cgi?id=14205 > > > > But your command was > > > > /kodi> ( setenv LD_AUDIT ./auditmod.so ; /usr/lib64/kodi/kodi.bin ) | & tee > > audit.log > > > > and it didn't crash. > > Likewise for: > pltenter: memset: dst=0x7ff43008ed78, src=0, len=8 > > I don't see this would segfault if `dst` has write permissions. If I try both LD_AUDIT=${PWD}/auditmod.so LD_PRELOAD=/lib64/libmemusage.so it simply crashes with a SIGSEGV werner@noether:/usr/src/werner/auditmod> LD_AUDIT=${PWD}/auditmod.so LD_PRELOAD=/lib64/libmemusage.so /usr/lib64/kodi/kodi.bin version: 2 Segmentation fault (core dumped) no output from auditmod.so ... only a core dump werner@noether:/usr/src/werner/auditmod> sudo coredumpctl | tail -n 1 Thu 2022-07-14 09:30:28 CEST 16275 223 50 SIGSEGV present /usr/lib64/kodi/kodi.bin werner@noether:/usr/src/werner/auditmod> sudo coredumpctl dump 16275 -o /tmp/core > dumpctl.log 2>&1
(In reply to Dr. Werner Fink from comment #24) > Created attachment 14209 [details] > dumpctl.log ... > > If I try both > > LD_AUDIT=${PWD}/auditmod.so LD_PRELOAD=/lib64/libmemusage.so > > it simply crashes with a SIGSEGV > > werner@noether:/usr/src/werner/auditmod> LD_AUDIT=${PWD}/auditmod.so > LD_PRELOAD=/lib64/libmemusage.so /usr/lib64/kodi/kodi.bin > version: 2 > Segmentation fault (core dumped) > > no output from auditmod.so ... only a core dump > > werner@noether:/usr/src/werner/auditmod> sudo coredumpctl | tail -n 1 > Thu 2022-07-14 09:30:28 CEST 16275 223 50 SIGSEGV present > /usr/lib64/kodi/kodi.bin > > werner@noether:/usr/src/werner/auditmod> sudo coredumpctl dump 16275 -o > /tmp/core > dumpctl.log 2>&1 So they can't be used together. Please find out the parameters passed to memset when crash happens. Have you tried valgrind?
Created attachment 14218 [details] trace.log Just tried valgrind and preloading /lib64/libmemusage.so(In reply to H.J. Lu from comment #25) > (In reply to Dr. Werner Fink from comment #24) > > Created attachment 14209 [details] > > dumpctl.log > ... > > > > If I try both > > > > LD_AUDIT=${PWD}/auditmod.so LD_PRELOAD=/lib64/libmemusage.so > > > > it simply crashes with a SIGSEGV > > > > werner@noether:/usr/src/werner/auditmod> LD_AUDIT=${PWD}/auditmod.so > > LD_PRELOAD=/lib64/libmemusage.so /usr/lib64/kodi/kodi.bin > > version: 2 > > Segmentation fault (core dumped) > > > > no output from auditmod.so ... only a core dump > > > > werner@noether:/usr/src/werner/auditmod> sudo coredumpctl | tail -n 1 > > Thu 2022-07-14 09:30:28 CEST 16275 223 50 SIGSEGV present > > /usr/lib64/kodi/kodi.bin > > > > werner@noether:/usr/src/werner/auditmod> sudo coredumpctl dump 16275 -o > > /tmp/core > dumpctl.log 2>&1 > > So they can't be used together. Please find out the parameters passed to > memset when crash happens. Have you tried valgrind? Just tried valgrind and preloading /lib64/libmemusage.so ... but this looks more like valgrind is handled by libmemusage. At least it does not crash
libmemusage.so implements free, realloc, malloc and calloc. Glibc also has posix_memalign, aligned_alloc, valloc, memalign and pvalloc. If any of them are used, free in libmemusage.so may free the wrong memory.
Created attachment 14224 [details] log2 --- ltrace log (In reply to H.J. Lu from comment #27) > libmemusage.so implements free, realloc, malloc and calloc. Glibc also has > posix_memalign, aligned_alloc, valloc, memalign and pvalloc. If any of them > are > used, free in libmemusage.so may free the wrong memory. I've tried the following ( setenv LD_PRELOAD /lib64/libmemusage.so ; setenv MEMUSAGE_OUTPUT /dev/null ; setenv MEMUSAGE_TRACE_MMAP yes ; ltrace -f -s 1024 -o log2 -e 'malloc+free+memset-@libc.so*' /usr/lib64/kodi/kodi.bin ) as well as ( setenv LD_PRELOAD /lib64/libmemusage.so ; setenv MEMUSAGE_OUTPUT /dev/null ; setenv MEMUSAGE_TRACE_MMAP yes ; strace -f -s 1024 -o log /usr/lib64/kodi/kodi.bin ) .. yes I'm a tcsh user :)
Maybe it is a combination of preloading libmemusage.so with a program using the libsqlite3.so.0 as 68701503120 bytes seems to be very large for the address 0x2db2320 as well as this address seems not be (m)allocated before as the addresses before
(In reply to Dr. Werner Fink from comment #29) > Maybe it is a combination of preloading libmemusage.so with a program using > the libsqlite3.so.0 as 68701503120 bytes seems to be very large for the > address 0x2db2320 as well as this address seems not be (m)allocated before > as the addresses before Is there a reason to think this is a bug with memset and not invalid parameters?
(In reply to Noah Goldstein from comment #30) > (In reply to Dr. Werner Fink from comment #lib29) > > Maybe it is a combination of preloading libmemusage.so with a program using > > the libsqlite3.so.0 as 68701503120 bytes seems to be very large for the > > address 0x2db2320 as well as this address seems not be (m)allocated before > > as the addresses before > Is there a reason to think this is a bug with memset and not invalid > parameters? If this is a bug with memset ... I don't know. What I know is that the bug happens if libmemusage.so is preloaded. And I'm not the only one, see https://bugzilla.opensuse.org/show_bug.cgi?id=1201047#c14 interestingly if I use heaptrack (https://userbase.kde.org/Heaptrack) this crash does not happen. Also various valgrind tools do not trigger such a crash.
For me it looks like a problem with (lib)sqlite3 and its memory managment and libmemusage.so 35108 35109 if( new_ht==0 ) return 0; 35110 sqlite3_free(pH->ht); 35111 pH->ht = new_ht; 35112 pH->htsize = new_size = sqlite3MallocSize(new_ht)/sizeof(struct _ht); 35113 memset(new_ht, 0, new_size*sizeof(struct _ht)); 35114 for(elem=pH->first, pH->first=0; elem; elem = next_elem){ 35115 unsigned int h = strHash(elem->pKey) % new_size; 35116 next_elem = elem->next; 35117 insertElement(pH, &new_ht[h], elem); (gdb) print new_ht $8 = (struct _ht *) 0x1ba9330 (gdb) print *new_ht $9 = {count = 0, chain = 0x0} (gdb) print new_size $10 = 4293843945 (gdb) print pH->htsize $11 = 0
Simple reproducer touch mydata.db LD_PRELOAD=/lib64/libmemusage.so sqlite3 mydata.db Segmentation fault (core dumped) man -f sqlite3 sqlite3 (1) - A command line interface for SQLite version 3 sqlite3 (n) - an interface to the SQLite3 database engine