1 Aug
2010
1 Aug
'10
10:46 p.m.
Hi,
I've encountered a segfault using the latest perdition tip when using
multiple addresses with the bind_address option. Perdition works fine
when using only a single address to bind to:
Single address:
$ ./perdition -P IMAP4 --debug --no_daemon -u
perdition --pid_file /var/run/perdition/imap4.pid --bind_address 127.0.0.1
# ... nothing (works fine)
Multiple addresses:
$ ./perdition -P IMAP4 --debug --no_daemon -u
perdition --pid_file /var/run/perdition/imap4.pid --bind_address 127.0.0.1,10.0.0.1
*** glibc detected *** perdition: daemon: malloc(): memory corruption: 0x0000000000638ed0
***
======= Backtrace: =========
/lib/libc.so.6(+0x72966)[0x7a413bbbf966]
/lib/libc.so.6(+0x75a41)[0x7a413bbc2a41]
/lib/libc.so.6(__libc_malloc+0x70)[0x7a413bbc4800]
/usr/lib/libvanessa_socket.so.2(vanessa_socket_server_bindv+0x37)[0x7a413d27d1b7]
perdition: daemon(main+0x51e)[0x41474e]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7a413bb6bbbd]
perdition: daemon[0x406f09]
======= Memory map: ========
00400000-00427000 r-xp 00000000 fd:06 272487
/tmp/perdition/perdition/perdition
00626000-00627000 r--p 00026000 fd:06 272487
/tmp/perdition/perdition/perdition
00627000-00629000 rw-p 00027000 fd:06 272487
/tmp/perdition/perdition/perdition
00629000-00656000 rw-p 00000000 00:00 0 [heap]
7a4134000000-7a4134021000 rw-p 00000000 00:00 0
7a4134021000-7a4138000000 ---p 00000000 00:00 0
7a413acca000-7a413ace0000 r-xp 00000000 fd:06 135113
/lib64/libgcc_s.so.1
7a413ace0000-7a413aedf000 ---p 00016000 fd:06 135113
/lib64/libgcc_s.so.1
7a413aedf000-7a413aee0000 r--p 00015000 fd:06 135113
/lib64/libgcc_s.so.1
7a413aee0000-7a413aee1000 rw-p 00016000 fd:06 135113
/lib64/libgcc_s.so.1
7a413aee1000-7a413aeec000 r-xp 00000000 fd:06 265485
/lib64/libnss_files-2.11.2.so
7a413aeec000-7a413b0ec000 ---p 0000b000 fd:06 265485
/lib64/libnss_files-2.11.2.so
7a413b0ec000-7a413b0ed000 r--p 0000b000 fd:06 265485
/lib64/libnss_files-2.11.2.so
7a413b0ed000-7a413b0ee000 rw-p 0000c000 fd:06 265485
/lib64/libnss_files-2.11.2.so
7a413b0ee000-7a413b0f8000 r-xp 00000000 fd:06 265503
/lib64/libnss_nis-2.11.2.so
7a413b0f8000-7a413b2f7000 ---p 0000a000 fd:06 265503
/lib64/libnss_nis-2.11.2.so
7a413b2f7000-7a413b2f8000 r--p 00009000 fd:06 265503
/lib64/libnss_nis-2.11.2.so
7a413b2f8000-7a413b2f9000 rw-p 0000a000 fd:06 265503
/lib64/libnss_nis-2.11.2.so
7a413b2f9000-7a413b30e000 r-xp 00000000 fd:06 265489
/lib64/libnsl-2.11.2.so
7a413b30e000-7a413b50d000 ---p 00015000 fd:06 265489
/lib64/libnsl-2.11.2.so
7a413b50d000-7a413b50e000 r--p 00014000 fd:06 265489
/lib64/libnsl-2.11.2.so
7a413b50e000-7a413b50f000 rw-p 00015000 fd:06 265489
/lib64/libnsl-2.11.2.so
7a413b50f000-7a413b511000 rw-p 00000000 00:00 0
7a413b511000-7a413b518000 r-xp 00000000 fd:06 265508
/lib64/libnss_compat-2.11.2.so
7a413b518000-7a413b717000 ---p 00007000 fd:06 265508
/lib64/libnss_compat-2.11.2.so
7a413b717000-7a413b718000 r--p 00006000 fd:06 265508
/lib64/libnss_compat-2.11.2.so
7a413b718000-7a413b719000 rw-p 00007000 fd:06 265508
/lib64/libnss_compat-2.11.2.so
7a413b719000-7a413b730000 r-xp 00000000 fd:06 265495
/lib64/libpthread-2.11.2.so
7a413b730000-7a413b92f000 ---p 00017000 fd:06 265495
/lib64/libpthread-2.11.2.so
7a413b92f000-7a413b930000 r--p 00016000 fd:06 265495
/lib64/libpthread-2.11.2.so
7a413b930000-7a413b931000 rw-p 00017000 fd:06 265495
/lib64/libpthread-2.11.2.so
7a413b931000-7a413b935000 rw-p 00000000 00:00 0
7a413b935000-7a413b94b000 r-xp 00000000 fd:06 145397
/lib64/libz.so.1.2.5
7a413b94b000-7a413bb4b000 ---p 00016000 fd:06 145397
/lib64/libz.so.1.2.5
7a413bb4b000-7a413bb4c000 r--p 00016000 fd:06 145397
/lib64/libz.so.1.2.5
7a413bb4c000-7a413bb4d000 rw-p 00017000 fd:06 145397
/lib64/libz.so.1.2.5
7a413bb4d000-7a413bc9d000 r-xp 00000000 fd:06 265496
/lib64/libc-2.11.2.so
7a413bc9d000-7a413be9c000 ---p 00150000 fd:06 265496
/lib64/libc-2.11.2.so
7a413be9c000-7a413bea0000 r--p 0014f000 fd:06 265496
/lib64/libc-2.11.2.so
7a413bea0000-7a413bea1000 rw-p 00153000 fd:06 265496
/lib64/libc-2.11.2.so
7a413bea1000-7a413bea6000 rw-p 00000000 00:00 0
7a413bea6000-7a413bed8000 r-xp 00000000 fd:06 158141
/usr/lib64/libidn.so.11.6.2
7a413bed8000-7a413c0d7000 ---p 00032000 fd:06 158141
/usr/lib64/libidn.so.11.6.2
7a413c0d7000-7a413c0d8000 r--p 00031000 fd:06 158141
/usr/lib64/libidn.so.11.6.2
7a413c0d8000-7a413c0d9000 rw-p 00032000 fd:06 158141
/usr/lib64/libidn.so.11.6.2
7a413c0d9000-7a413c24d000 r-xp 00000000 fd:06 145408
/usr/lib64/libdb-4.8.so
7a413c24d000-7a413c44d000 ---p 00174000 fd:06 145408
/usr/lib64/libdb-4.8.so
7a413c44d000-7a413c44f000 r--p 00174000 fd:06 145408
/usr/lib64/libdb-4.8.so
7a413c44f000-7a413c452000 rw-p 00176000 fd:06 145408
/usr/lib64/libdb-4.8.so
7a413c452000-7a413c5d4000 r-xp 00000000 fd:06 265061
/usr/lib64/libcrypto.so.1.0.0
7a413c5d4000-7a413c7d4000 ---p 00182000 fd:06 265061
/usr/lib64/libcrypto.so.1.0.0
7a413c7d4000-7a413c7ed000 r--p 00182000 fd:06 265061
/usr/lib64/libcrypto.so.1.0.0
7a413c7ed000-7a413c7f7000 rw-p 0019b000 fd:06 265061
/usr/lib64/libcrypto.so.1.0.0
7a413c7f7000-7a413c7fb000 rw-p 00000000 00:00 0
7a413c7fb000-7a413c84f000 r-xp 00000000 fd:06 265077
/usr/lib64/libssl.so.1.0.0
7a413c84f000-7a413ca4f000 ---p 00054000 fd:06 265077
/usr/lib64/libssl.so.1.0.0
7a413ca4f000-7a413ca52000 r--p 00054000 fd:06 265077
/usr/lib64/libssl.so.1.0.0
7a413ca52000-7a413ca57000 rw-p 00057000 fd:06 265077
/usr/lib64/libssl.so.1.0.0
7a413ca57000-7a413ca59000 r-xp 00000000 fd:06 265497
/lib64/libdl-2.11.2.so
7a413ca59000-7a413cc59000 ---p 00002000 fd:06 265497
/lib64/libdl-2.11.2.so
7a413cc59000-7a413cc5a000 r--p 00002000 fd:06 265497
/lib64/libdl-2.11.2.so
7a413cc5a000-7a413cc5b000 rw-p 00003000 fd:06 265497
/lib64/libdl-2.11.2.so
7a413cc5b000-7a413cc67000 r-xp 00000000 fd:06 159820
/lib64/libpam.so.0.82.2
I was able to bisect this with hg and traced the bug to:
The first bad revision is:
changeset: 695:b8475aa0d891
user: Simon Horman <horms(a)verge.net.au>
date: Sat Nov 28 17:23:14 2009 +1100
summary: perdition: Use signed and unsigned types consistently
The hunk introducing the problem is at:
http://hg.vergenet.net/perdition/perdition/rev/b8475aa0d891#l4.38
which is basically:
- fromv = (char **)malloc(((nfrom * 2) + 1) *
sizeof(char *));
+ fromv = malloc(((nfrom * 2) + 1));
This assumes that sizeof(char *) == 1, which is not correct.
The proposed fix is attached.
It works fine here with multi- and single address binding :-)
# HG changeset patch
# User John Feuerstein <john(a)feurix.com>
# Date 1280701535 -7200
# Node ID af5baa34ebba0770dca17e34665fcb9f3571713c
# Parent aeff92473a55f077295220c1ff5ea7eb0ba82e76
perdition: malloc() enough memory
This change fixes a bug introduced by changeset 695:b8475aa0d891,
"perdition: Use signed and unsigned types consistently":
- fromv = (char **)malloc(((nfrom * 2) + 1) * sizeof(char *));
+ fromv = malloc(((nfrom * 2) + 1));
This falsely assumes that sizeof(char *) == 1, which is wrong.
The result is a segfault if bind_address is set to more than
one address, for example:
bind_address 127.0.0.1,192.168.10.1
diff -r aeff92473a55 -r af5baa34ebba perdition/perdition.c
--- a/perdition/perdition.c Sat Jul 31 14:23:46 2010 +0900
+++ b/perdition/perdition.c Mon Aug 02 00:25:35 2010 +0200
@@ -579,7 +579,7 @@
else
nfrom = 1;
- fromv = malloc(((nfrom * 2) + 1));
+ fromv = malloc(((nfrom * 2) + 1) * sizeof(unsigned char*));
if (!fromv) {
VANESSA_LOGGER_DEBUG_ERRNO("malloc fromv");
VANESSA_LOGGER_ERR("Fatal error allocating memory. Exiting.");
Best regards,
John Feuerstein
2 Aug
2 Aug
1:34 a.m.
On Mon, Aug 02, 2010 at 12:46:37AM +0200, John Feuerstein wrote:
Hi,
I've encountered a segfault using the latest perdition tip when using
multiple addresses with the bind_address option. Perdition works fine
when using only a single address to bind to:
Single address:
> $ ./perdition -P IMAP4 --debug --no_daemon -u perdition --pid_file
/var/run/perdition/imap4.pid --bind_address 127.0.0.1
>
> # ... nothing (works fine)
Hi John,
thanks for bringing that to my attention. Yes, I see the segmentation fault too.
1:38 p.m.
On Mon, Aug 02, 2010 at 10:34:22AM +0900, Simon Horman wrote:
On Mon, Aug 02, 2010 at 12:46:37AM +0200, John
Feuerstein wrote:
Hi John,
could you see if the following patch resolves the problem?
From: Simon Horman <horms(a)verge.net.au>
Allocate enough space for fromv
This manifests as a crash-bug on start-up
in the case where more than one address is supplied to
the bind_address configuration option.
Reported-by: John Feuerstein <john(a)feurix.com>
Signed-off-by: Simon Horman <horms(a)verge.net.au>
diff -r aeff92473a55 perdition/perdition.c
--- a/perdition/perdition.c Sat Jul 31 14:23:46 2010 +0900
+++ b/perdition/perdition.c Mon Aug 02 22:35:26 2010 +0900
@@ -579,7 +579,7 @@
else
nfrom = 1;
- fromv = malloc(((nfrom * 2) + 1));
+ fromv = malloc(sizeof(*fromv) * ((nfrom * 2) + 1));
if (!fromv) {
VANESSA_LOGGER_DEBUG_ERRNO("malloc fromv");
VANESSA_LOGGER_ERR("Fatal error allocating memory. Exiting.");
Hi,
I've encountered a segfault using the latest perdition tip when using
multiple addresses with the bind_address option. Perdition works fine
when using only a single address to bind to:
Single address:
> $ ./perdition -P IMAP4 --debug --no_daemon -u perdition --pid_file
/var/run/perdition/imap4.pid --bind_address 127.0.0.1
>
> # ... nothing (works fine)
Hi John,
thanks for bringing that to my attention. Yes, I see the segmentation fault too.
3:54 p.m.
New subject: PATCH: Fix segfault with multiple bind addresses
Hi Simon,
On 08/02/2010 03:38 PM, Simon Horman wrote:
could you see if the following patch resolves the
problem?
From: Simon Horman <horms(a)verge.net.au>
Allocate enough space for fromv
This manifests as a crash-bug on start-up
in the case where more than one address is supplied to
the bind_address configuration option.
Reported-by: John Feuerstein <john(a)feurix.com>
Signed-off-by: Simon Horman <horms(a)verge.net.au>
diff -r aeff92473a55 perdition/perdition.c
--- a/perdition/perdition.c Sat Jul 31 14:23:46 2010 +0900
+++ b/perdition/perdition.c Mon Aug 02 22:35:26 2010 +0900
@@ -579,7 +579,7 @@
else
nfrom = 1;
- fromv = malloc(((nfrom * 2) + 1));
+ fromv = malloc(sizeof(*fromv) * ((nfrom * 2) + 1));
if (!fromv) {
VANESSA_LOGGER_DEBUG_ERRNO("malloc fromv");
VANESSA_LOGGER_ERR("Fatal error allocating memory. Exiting.");
yes, I've just build the tip with this patch applied and it fixes the
problem for me! :-)
Regards,
John
3 Aug
3 Aug
12:57 a.m.
On Mon, Aug 02, 2010 at 05:54:24PM +0200, John Feuerstein wrote:
Hi Simon,
On 08/02/2010 03:38 PM, Simon Horman wrote:
Thanks, I have pushed the change.
could you see if the following patch resolves the
problem?
From: Simon Horman <horms(a)verge.net.au>
Allocate enough space for fromv
This manifests as a crash-bug on start-up
in the case where more than one address is supplied to
the bind_address configuration option.
Reported-by: John Feuerstein <john(a)feurix.com>
Signed-off-by: Simon Horman <horms(a)verge.net.au>
diff -r aeff92473a55 perdition/perdition.c
--- a/perdition/perdition.c Sat Jul 31 14:23:46 2010 +0900
+++ b/perdition/perdition.c Mon Aug 02 22:35:26 2010 +0900
@@ -579,7 +579,7 @@
else
nfrom = 1;
- fromv = malloc(((nfrom * 2) + 1));
+ fromv = malloc(sizeof(*fromv) * ((nfrom * 2) + 1));
if (!fromv) {
VANESSA_LOGGER_DEBUG_ERRNO("malloc fromv");
VANESSA_LOGGER_ERR("Fatal error allocating memory. Exiting.");
yes, I've just build the tip with this patch applied and it fixes the
problem for me! :-)
5039
days inactive
5041
days old
4 comments
2 participants
participants (2)
-
John Feuerstein -
Simon Horman