Hello Marc,
> but i don't see much more withour bt full, do i understand correctly ?
I just wanted to see the line from dmesg, where we can see which
address caused the error. And wanted to see all for the same crash.
And I had not realized that the callc instruction really have to
write its return address onto the stack where the ret instruction
can take it later.
[1963749.763571] logrotate[754]: segfault at 7fff97c94a28 ip
000055e3239db88a sp 00007fff97c94a30 error 6 in logrotate[55e3239cf000+11000]
frame #0: rsp 0x7fff97c94a30 0x7fff97c94a30
frame #1: rsp 0x7fff984ad620 0x7fff984ad620
So the line from dmesg shows we want to write to address 7fff97c94a28
that is really near the stack pointer $rsp in the frame #0 (rotateLogSet).
0x7fff984ad620 - 0x7fff97c94a30 = 0x818BF0 == 0n8489968
$ ulimit -a
...
stack size (kbytes, -s) 8192
The difference between the stack pointers in rotateLogSet and main
is around 8291 kb. And what I could read in the net the default
maximum stack size is 8192 kb. Therefore we are trying to write
beyond our stack limit?
Ok, one source of stack exhaustion is recursion, but there
is no evidence for this as we have just a few frames.
The other source that I know of are large function local
arrays and that led me to line 1874:
1870 int rotateLogSet(struct logInfo *log, int force)
1871 {
1872 int i, j;
1873 int hasErrors = 0;
1874 int logHasErrors[log->numFiles];
1875 int numRotated = 0;
The array size depends dynamically on log->numFiles.
But it would take a lot of files to get to that limit ...
(but you wrote that you rotate a lot data)
So could you please provide the output of following command again:
coredumpctl gdb 754
print log->numFiles
Kind regards,
Bernhard
