Versions: * 2.2.3.1 * 2.2.3 are available. Reproducible: Always According to this bug: https://sourceforge.net/tracker/index.php?func=detail&aid=1636761&group_id=68910&atid=522791 2.2.3.1 may have issues with very large log files. Perhaps add only 2.2.3 for now?
Large files are not the only problem. That version is buggy and users report about once a week about segfaults. If I'll find the reason for that segfaults, I'll bump new version. So sorry, but WONTFIX for now.
And another note. Patch for sprintf does not fix segfaults users experience.
Volkov, are you referring to both 2.2.3 and 2.2.3.1 or just 2.2.3.1 when you say 'that version is buggy' ?
I mean both versions.
In comment 2 were you referring to: [ 1647390 ] fix for segmentation fault in sarg-2.2.3.1 https://sourceforge.net/tracker/index.php?func=detail&aid=1647390&group_id=68910&atid=522793
Yes. That patch fixes the problem in the wrong place, while people experience segfault with the following backtrace: (gdb) backtrace #0 0x00002aaaaac32600 in strlen () from /lib64/tls/libc.so.6 #1 0x00002aaaaac04a90 in vfprintf () from /lib64/tls/libc.so.6 #2 0x00002aaaaac1fcd9 in vsprintf () from /lib64/tls/libc.so.6 #3 0x00002aaaaac0aec8 in sprintf () from /lib64/tls/libc.so.6 #4 0x000000000040dbd4 in topuser () at topuser.c:400 #5 0x000000000040b90e in gerarel () at report.c:334 #6 0x0000000000408b2e in main (argc=<value optimized out>, argv=0x7fffffd20868) at log.c:1402 Now you know where is the problem. If you'll have a patch reopen, please :)
*** Bug 183529 has been marked as a duplicate of this bug. ***
Created attachment 123395 [details, diff] Log.c , sprintf patch
Created attachment 123396 [details, diff] report.c, patch for segfault if there is user named "*log*"
Sorry for issuing Bug 183529, I have not searched correctly the Bug List. There is actually a new patch on SARG's website : https://sourceforge.net/tracker/index.php?func=detail&aid=1733337&group_id=68910&atid=522793 I had no user named "log"-something, so I manually added some entries : gtl-proxy squid # sarg -l test.log SARG: Records in file: 118967, reading: 100.00% Segmentation fault After applying patch : gtl-proxy squid # sarg -l test.log SARG: Records in file: 118967, reading: 100.00% SARG: Successful report generated on /var/www/localhost/htdocs/squid-reports/2007Jun23-2007Jun29 Included are the two patches, Add : epatch ${FILESDIR}/sarg-2.2.3.1-log.patch epatch ${FILESDIR}/sarg-2.2.3.1-report.patch To the end of src_unpack() Regards,
To make this clear. New version of sarg has bug and it segfaults like this: http://tech.groups.yahoo.com/group/orso/message/3922 (gdb) run sarg -zx Starting program: /usr/bin/sarg sarg -zx SARG: Init SARG: Loading configuration from: /usr/local/sarg/sarg.conf SARG: TAG: access_log /var/log/squid/new-access.log SARG: TAG: title Internet Access Reports SARG: TAG: output_dir /srv/www/htdocs/web-reports SARG: TAG: lastlog 30 SARG: Parameters: SARG: SARG: Hostname or IP address (-a) = SARG: Useragent log (-b) = SARG: Exclude file (-c) = SARG: Date from-until (-d) = SARG: Email address to send reports (-e) = SARG: Config file (-f) = /usr/local/sarg/sarg.conf SARG: Date format (-g) = USA (mm/dd/yyyy) SARG: IP report (-i) = No SARG: Input log (-l) = /var/log/squid/new-access.log SARG: Resolve IP Address (-n) = No SARG: Output dir (-o) = /srv/www/htdocs/web-reports/ SARG: Use Ip Address instead of userid (-p) = No SARG: Accessed site (-s) = SARG: Time (-t) = SARG: User (-u) = SARG: Temporary dir (-w) = /tmp SARG: Debug messages (-x) = Yes SARG: Process messages (-z) = Yes SARG: SARG: sarg version: 2.2.3.1 Jan-02-2007 SARG: Maximum file descriptor: cur=1024 max=1024, changed to cur=20000 max=20000 SARG: Reading access log file: /var/log/squid/new-access.log SARG: (util) tbuf=2007Feb15eading: 0.00% SARG: (util) period=2007Feb15- SARG: Records in file: 5, reading: 100.00% SARG: Records read: 5, written: 5, excluded: 0 SARG: Squid log format SARG: (util) data=02/15/2007 SARG: (util) tbuf=2007Feb15 SARG: (util) period=2007Feb15-2007Feb15 SARG: Period: 2007Feb15-2007Feb15 SARG: pre-sorting files SARG: File: /srv/www/htdocs/web-reports/2007Feb15-2007Feb15 already exists, moved to /srv/www/htdocs/web-reports/2007Feb15-2007Feb15.9 SARG: (util) dirname=/srv/www/htdocs/web-reports/2007Feb15-2007Feb15 SARG: (util) wdir=/srv/www/htdocs/web-reports/2007Feb15-2007Feb15 SARG: Making period file SARG: Making file: /tmp/sarg/192.168.0.131 SARG: Making file: /tmp/sarg/192.168.0.132 SARG: Making file: /tmp/sarg/192.168.0.145 SARG: Sorting file: /tmp/sarg/192.168.0.131 SARG: Sorting file: /tmp/sarg/192.168.0.132 SARG: Sorting file: /tmp/sarg/192.168.0.145 Program received signal SIGSEGV, Segmentation fault. 0x00002aaaaac32600 in strlen () from /lib64/tls/libc.so.6 (gdb) bt #0 0x00002aaaaac32600 in strlen () from /lib64/tls/libc.so.6 #1 0x00002aaaaac04a90 in vfprintf () from /lib64/tls/libc.so.6 #2 0x00002aaaaac1fcd9 in vsprintf () from /lib64/tls/libc.so.6 #3 0x00002aaaaac0aec8 in sprintf () from /lib64/tls/libc.so.6 #4 0x000000000040dbd4 in topuser () at topuser.c:400 #5 0x000000000040b90e in gerarel () at report.c:334 #6 0x0000000000408b2e in main (argc=<value optimized out>, argv=0x7fffffd20868) at log.c:1402 As far as I see neither of patches address this issue. I did not mange to reproduce this bug but there was at least 3 similar reports. So no. I will take responsibility and bump this version of sarg while this issue is not addressed. Sorry. On the other hand, thank you, Jean-Jacques, for updating this report. If one day somebody manages to fix this issue, I'll bump sarg with this bugs fixed too.
I would really want to help, thus I also compiled on x86_64, and was able to get the same segfault with the 5 entries discussed on http://tech.groups.yahoo.com/group/orso/message/3922 . I found the bug in util.c (function fixnum2) : a char* pointer is returned from a locally defined buffer (ref[]) -> add a "static" in front of the definition and it will be OK. I would also add the same static in function fixnum (same principle). --- util.c.old 2007-07-01 22:32:50.000000000 +0200 +++ util.c 2007-07-01 22:33:10.000000000 +0200 @@ -414,7 +414,7 @@ char num[MAXIMO]; char buf[MAXIMO * 2]; char *pbuf; - char ret[MAXIMO * 2]; + static char ret[MAXIMO * 2]; char *pret; register int i, j, k; static char abbrev[30]; @@ -507,7 +507,7 @@ char num[MAXIMO]; char buf[MAXIMO * 2]; char *pbuf; - char ret[MAXIMO * 2]; + static char ret[MAXIMO * 2]; char *pret; register int i, j, k; static char abbrev[30];
Jean-Jacques, thank you for your investigation. Could you, please, post this patches in upstream bugzilla and ask people on orso mailing list to test this fix?
(In reply to comment #13) > Jean-Jacques, thank you for your investigation. Could you, please, post this > patches in upstream bugzilla and ask people on orso mailing list to test this > fix? > Back from vacation, I see two positive answers, see : https://sourceforge.net/tracker/index.php?func=detail&aid=1746289&group_id=68910&atid=522793
reopening.
Created attachment 127472 [details, diff] sarg-2.2.3.1-lots-of-compiler-warnings.patch Thank you Jean-Jacques. I've managed to reproduce the bug and seems that your fix works. The other crash reported upstream seems to be fixed by this patch (it also includes Log.c , sprintf patch created by Francesco). I'll mail to the mailing list and we'll see if people find more problems... If there are no problems I'll bump it.
sarg's mailing list became silent (either it does not work). I've bumped version in my overlay so if anybody wants to play with it take ebuild and patches here: http://overlays.gentoo.org/dev/pva/browser/net-analyzer/sarg
Sarg mailing list is partially dead and development in completely stalled. I've received no feedback on mailing list. But upstream still promises to return back to development, so currently I'd like to resolve this bug as LATER.
*** Bug 206797 has been marked as a duplicate of this bug. ***
Reopening, as sarg is bumped...
Ok, sarg-2.2.4 is released and fixes security vulnerablility. That's why I've bumped it with hope for best. It'll be stabilized very soon (actually already stable on x86). Enjoy. FIXED.
