Bug#722484: Info received (libdspam7-drv-hash segfaults since 3.10.2+dfsg-10)

2013-10-09 Thread Thomas Preud'homme 
Control: reopen 722484 m...@blackshift.org

Le lundi 7 octobre 2013 23:01:47, vous avez écrit :
 Hello
 
 I've deleted /var/spool/dspam/data and let dspam deliver a mail, that
 produces this backtrace:
 
 #0  0xb6f118ec in raise () from /lib/arm-linux-gnueabi/libpthread.so.0
 No symbol table info available.
 #1  0xb6a5acf4 in __aeabi_ldiv0 () from
 /usr/lib/arm-linux-gnueabi/dspam/libhash_drv.so No symbol table info
 available.
 #2  0xb6a59b9c in _hash_drv_seek (map=map@entry=0xb57073d8,
 offset=offset@entry=16147856, hashcode=optimized out,
 flags=flags@entry=1) at hash_drv.c:1194 header = optimized out
 rec = optimized out
 fpos = optimized out
 iterations = 0

Ok, this bug was very likely introduced with the patch I made to handle 
corrupted css file. Unfortunetely I don't have the time to fix the patch now. 
I'm very busy for a few weeks but I'll try to take a look at it as soon as 
possible.

Best regards.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#722484: Info received (libdspam7-drv-hash segfaults since 3.10.2+dfsg-10)

2013-10-09 Thread Marc Kleine-Budde 
On 10/09/2013 02:45 PM, Thomas Preud'homme wrote:
 I've deleted /var/spool/dspam/data and let dspam deliver a mail, that
 produces this backtrace:

 #0  0xb6f118ec in raise () from /lib/arm-linux-gnueabi/libpthread.so.0
 No symbol table info available.
 #1  0xb6a5acf4 in __aeabi_ldiv0 () from
 /usr/lib/arm-linux-gnueabi/dspam/libhash_drv.so No symbol table info
 available.
 #2  0xb6a59b9c in _hash_drv_seek (map=map@entry=0xb57073d8,
 offset=offset@entry=16147856, hashcode=optimized out,
 flags=flags@entry=1) at hash_drv.c:1194 header = optimized out
 rec = optimized out
 fpos = optimized out
 iterations = 0
 
 Ok, this bug was very likely introduced with the patch I made to handle 
 corrupted css file. Unfortunetely I don't have the time to fix the patch now. 

Yes the bug was introduced between 3.10.2+dfsg-9 and 3.10.2+dfsg-10. As
I'm running -9 without problems.

Although the incremental diff from -9 to -10 doesn't look suspicious at
the first glance:

 diff --git a/src/hash_drv.c b/src/hash_drv.c
 index 349b491..daae2e7 100644
 --- a/src/hash_drv.c
 +++ b/src/hash_drv.c
 @@ -1187,32 +1187,36 @@ unsigned long _hash_drv_seek(
unsigned long fpos;
unsigned long iterations = 0;
 
if (offset = map-file_len)
  return 0;
 
fpos = sizeof(struct _hash_drv_header) +
  ((hashcode % header-hash_rec_max) * sizeof(struct 
 _hash_drv_spam_record));


According to the backtrace's line number the diff-by-zero should happen
here. But the modulo, which is IIRC implemented on ARM as
divide/multiply/difference, was here all the time.

Was there a compiler change? Maybe some new optimisations brakes the code.

rec = (void *)((unsigned long) map-addr + offset + fpos);
 -  while(rec-hashcode != hashcode /* Match token */
 -rec-hashcode != 0/* Insert on empty */
 -iterations  map-max_seek) /* Max Iterations  */
 +  while(rec + sizeof(*rec) = map-file_len   /* not end of file */
 +rec-hashcode != hashcode /* Match token */
 +rec-hashcode != 0/* Insert on empty */
 +iterations  map-max_seek) /* Max Iterations  */
{
  iterations++;
  fpos += sizeof(struct _hash_drv_spam_record);
 
  if (fpos = (header-hash_rec_max * sizeof(struct 
 _hash_drv_spam_record)))
fpos = sizeof(struct _hash_drv_header);
  rec = (void *)((unsigned long) map-addr + offset + fpos);
}
 
 +  if (rec + sizeof(*rec)  map-file_len)
 +return 0;
 +
if (rec-hashcode == hashcode)
  return fpos;
 
if (rec-hashcode == 0  (flags  HSEEK_INSERT))
  return fpos;
 
return 0;
  }

 I'm very busy for a few weeks but I'll try to take a look at it as soon as 
 possible.

Thanks,
Marc



signature.asc
Description: OpenPGP digital signature

Bug#722484: Info received (libdspam7-drv-hash segfaults since 3.10.2+dfsg-10)

2013-10-09 Thread Thomas Preud'homme 
Le mercredi 9 octobre 2013 14:56:23, vous avez écrit :
 
 Yes the bug was introduced between 3.10.2+dfsg-9 and 3.10.2+dfsg-10. As
 I'm running -9 without problems.
 
 Although the incremental diff from -9 to -10 doesn't look suspicious at
 
 the first glance:
  diff --git a/src/hash_drv.c b/src/hash_drv.c
  index 349b491..daae2e7 100644
  --- a/src/hash_drv.c
  +++ b/src/hash_drv.c
  @@ -1187,32 +1187,36 @@ unsigned long _hash_drv_seek(
  
 unsigned long fpos;
 unsigned long iterations = 0;
 
 if (offset = map-file_len)
 
   return 0;
 
 fpos = sizeof(struct _hash_drv_header) +
 
   ((hashcode % header-hash_rec_max) * sizeof(struct
   _hash_drv_spam_record));
 
 
 
 According to the backtrace's line number the diff-by-zero should happen
 here. But the modulo, which is IIRC implemented on ARM as
 divide/multiply/difference, was here all the time.
 
 Was there a compiler change? Maybe some new optimisations brakes the code.

Without having looked at the code, I suspect that hash_rec_max is updated from 
_hash_drv_seek's return value. Since I added a check to detect when the end of 
file is going to be reached, the function returns 0 in case where it was not 
the case before.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#722484: Info received (libdspam7-drv-hash segfaults since 3.10.2+dfsg-10)

2013-10-07 Thread Marc Kleine-Budde 
Hello

I've deleted /var/spool/dspam/data and let dspam deliver a mail, that
produces this backtrace:

#0  0xb6f118ec in raise () from /lib/arm-linux-gnueabi/libpthread.so.0
No symbol table info available.
#1  0xb6a5acf4 in __aeabi_ldiv0 () from 
/usr/lib/arm-linux-gnueabi/dspam/libhash_drv.so
No symbol table info available.
#2  0xb6a59b9c in _hash_drv_seek (map=map@entry=0xb57073d8, 
offset=offset@entry=16147856, hashcode=optimized out, flags=flags@entry=1) at 
hash_drv.c:1194
header = optimized out
rec = optimized out
fpos = optimized out
iterations = 0
#3  0xb6a59cc8 in _hash_drv_set_spamrecord (map=0xb57073d8, 
wrec=wrec@entry=0xb60fa1a8, map_offset=0) at hash_drv.c:1239
rec = optimized out
offset = 16147856
extents = optimized out
last_extent_size = optimized out
rec_offset = 0
#4  0xb6a59df4 in _ds_set_spamrecord (CTX=optimized out, token=optimized 
out, stat=0xb5733f08) at hash_drv.c:785
rec = {hashcode = 6670524186553311232, nonspam = 1, spam = 0}
s = optimized out
#5  0xb6f336cc in _ds_set_spamrecord (CTX=0xb57007a8, token=optimized out, 
stat=0xb5733f08) at storage_driver.c:133
ptr = optimized out
#6  0xb6a59ea4 in _ds_setall_spamrecords (CTX=0xb57007a8, diction=0xb570d4d0) 
at hash_drv.c:736
ds_term = 0xb5733ef8
ds_c = 0xb573d9e8
ret = -2
#7  0xb6f3352c in _ds_setall_spamrecords (CTX=CTX@entry=0xb57007a8, 
diction=diction@entry=0xb570d4d0) at storage_driver.c:94
ptr = optimized out
#8  0xb6f292c8 in _ds_operate (CTX=CTX@entry=0xb57007a8, headers=optimized 
out, body=optimized out) at libdspam.c:1099
errcode = 0
diction = 0xb570d4d0
ds_term = 0x0
ds_c = optimized out
heap_sort = 0xefda004f
whitelist_token = 11166914970
do_whitelist = optimized out
heap_sort_items = 27
#9  0xb6f29b64 in dspam_process (CTX=CTX@entry=0xb57007a8,
message=0xb5704b18 Received: from metis.ext.pengutronix.de 
(metis.ext.pengutronix.de [IPv6:2001:6f8:1178:4:290:27ff:fe1d:cc33])\n\t(using 
TLSv1 with ci
pher AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby...) 
at libdspam.c:573
tp1 = {tv_sec = 1381179424, tv_usec = 996780}
tp2 = {tv_sec = 160472, tv_usec = -1250944800}
tzp = {tz_minuteswest = -120, tz_dsttime = 0}
header = 0xb570ce68
body = 0xb5708400
spam_result = 0
is_toe = optimized out
is_undertrain = 0
retcode = 0
#10 0x00012510 in process_message (ATX=ATX@entry=0xb57009f0, 
message=message@entry=0xb5700688, username=username@entry=0xb57018c0 
m...@kleine-budde.de,
result_string=0x0, result_string@entry=0xb60fd3f4) at dspam.c:541
CTX = 0xb57007a8
components = optimized out
copyback = optimized out
have_signature = optimized out
result = optimized out
i = optimized out
internally_canned = 0
original_username = 0x0
#11 0x00013268 in process_users (ATX=ATX@entry=0xb57009f0, message=0x0, 
message@entry=0xb5701960) at dspam.c:1895
result_string = 0x0
result = optimized out
s = {st_dev = 0, __pad1 = 0, st_ino = 0, st_mode = 0, st_nlink = 0, 
st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 0, st_blksize = 0,
  st_blocks = 0, st_atim = {tv_sec = 0, tv_nsec = 0}, st_mtim = {tv_sec 
= 0, tv_nsec = 0}, st_ctim = {tv_sec = 0, tv_nsec = 0}, __unused4 = 0,
  __unused5 = 0}
username = 0xb57018c0 m...@kleine-budde.de
recipient = m...@kleine-budde.de, '\000' repeats 235 times
filename = /var/spool/dspam/opt-out/kleine-budde.de/marc.nodspam, 
'\000' repeats 2211 times...
optin = 0
optout = optimized out
i = optimized out
have_rcpts = optimized out
return_code = -1250949480
retcode = optimized out
node_nt = 0xb57018e0
node_rcpt = 0x0
c_nt = {iter_index = 0xb57018e0}
c_rcpt = {iter_index = 0x0}
parse_message = 0xb5700688
presult = 0x0
plus = optimized out
atsign = optimized out
mailbox = '\000' repeats 255 times
fout = 0x
#12 0x000164ac in process_connection (ptr=0x1b32e58) at daemon.c:738
processmode = '\000' repeats 255 times
server_ident = optimized out
TTX = 0x1b32e58
ATX = 0xb57009f0
input = optimized out
cmdline = 0xb5701938 DATA\r\n
token = optimized out
ptrptr = optimized out
message = 0xb5701960
parms = optimized out
p = optimized out
i = 8
locked = 8
invalid = optimized out
server_mode = 1
argv = {0x1cb00 dspam, 0xb5701848 --deliver=innocent,spam, 
0xb5701860 -d, 0xb5701863 %u, 0x0 repeats 60 times}
buf = 250 OK\000AM LMTP 3.10.2 Ready, '\000' repeats 996 times
tries = 0
argc = optimized out
fd = 0x0

regards,