Perdition-users August 2010

perdition-users@vergenet.net

10 participants
11 discussions

PATCH: Fix segfault with multiple bind addresses

by John Feuerstein

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

13 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Perdition-users August 2010