Jakub Zawadzki
changed
bug 7676
Comment # 12
on bug 7676
from Jakub Zawadzki
Hi,
(In reply to comment #11)
> I'm still seeing this problem with FreeBSD 9.0 running tshark 1.10.0. Has
> this patch been incorporated into 1.10.0 or are we talking about a new issue?
Same one.
Finally found some time to debug it on FreeBSD:
#8 0x08067e45 in iostat_packet (arg=0x2b4b9f80, pinfo=0xbfbfe570,
edt=0xbfbfe568, dummy=0x0) at tap-iostat.c:127
127 it->next = (io_stat_item_t *)g_malloc(sizeof(io_stat_item_t));
(gdb) print relative_time
$1 = 18446744071567319020
(gdb) print /x relative_time
$2 = 0xffffffff80501fec
(gdb) print pinfo->fd->rel_ts.secs
$3 = 2152
(gdb) print /x (guint64)((pinfo->fd->rel_ts.secs*1000000))
$4 = 0xffffffff8044ea00
(gdb) print /x (guint64)(( ((guint)pinfo->fd->rel_ts.secs)*1000000))
$5 = 0x8044ea00
Some small test program:
#include <stdio.h>
#include <time.h>
int main() {
unsigned long long rel_time;
time_t secs;
int nsecs;
secs = 2152;
nsecs = 100;
rel_time = (unsigned long long)((secs*1000000) + ((nsecs+500)/1000));
printf("%llx\n", rel_time);
return 0;
}
64 bits:
$ clang a.c -m64; ./a.out
8044ea00
32 bits:
$ clang a.c -m32; ./a.out
ffffffff8044ea00
So it's problem with sign extension (multiplication
pinfo->fd->rel_ts.secs*1000000) is done for signed time_t,
result of it is negative (in 32-bits) for secs >= 2148, after casting result to
unsigned long long, they got enlarged to *enormous* 64 bits value.
and we're doing loop
while (very_large_value >= very_small_value) {
// allocate some memory
very_small_value += 1s;
}
it can quickly eat whole memory :)
Patch for it's quite simple:
- relative_time = (guint64)((pinfo->fd->rel_ts.secs*1000000) +
((pinfo->fd->rel_ts.nsecs+500)/1000));
+ relative_time = (guint64)((pinfo->fd->rel_ts.secs*1000000U) +
((pinfo->fd->rel_ts.nsecs+500)/1000));
But whole code should be checked for 32 bits.
CCing Cal Turney.
Cheers,
Jakub.
You are receiving this mail because:
- You are watching all bug changes.