Re: [vchkpw] Vusaged segmentation fault on long names
I will be releasing a better fix shortly. My apologies for the late reply, I was busy moving. I can confirm that the newly released version no longer contains this bug and have updated all servers to the latest 5.4.28 version. Thanks for the fix! Sincerely, - Wouter van der Schagt !DSPAM:4aa9251c32712038326845!
Re: [vchkpw] Vusaged segmentation fault on long names
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wouter van der Schagt wrote: > Thank you for the quick reply! > >> Is this in 5.5? What are the steps to reproduce? I added the domain as >> you did above, and my vusaged binary from trunk is running as expected, >> returning data for the long domain name. > > No, this is in 5.4.28, not running 5.5 at the moment, I can reproduce by > creating a long domainname and starting vusaged. The problem appears in the MySQL module. The temporary fix: Edit vauth_munch_domain function, change declaration of tmpbuf size of 50 to 512. I will be releasing a better fix shortly. - -- /* Matt BrookingsGnuPG Key FAE0672C Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqer8IACgkQIwet2/rgZyydqQCdFleg33eYc3FxnTGjCGHvnJFc Yx0An3f/DTLsIGIEXjoV3735oWV/9TOs =ha7v -END PGP SIGNATURE-
Re: [vchkpw] Vusaged segmentation fault on long names
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wouter van der Schagt wrote: > No, this is in 5.4.28, not running 5.5 at the moment, I can reproduce by > creating a long domainname and starting vusaged. Ah. I see this as well. Looking into this. - -- /* Matt BrookingsGnuPG Key FAE0672C Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqelOUACgkQIwet2/rgZyzWggCeIM1s3tMYiTNt4habSGePofV/ Wy4AnjazC83jc0HlHLs1t5tQ+ijnjUrr =3+xW -END PGP SIGNATURE-
Re: [vchkpw] Vusaged segmentation fault on long names
Thank you for the quick reply! Is this in 5.5? What are the steps to reproduce? I added the domain as you did above, and my vusaged binary from trunk is running as expected, returning data for the long domain name. No, this is in 5.4.28, not running 5.5 at the moment, I can reproduce by creating a long domainname and starting vusaged. This would seem to indicate that the issue occurred somewhere in vpopmail's vauth_getall call, or in MySQL itself. Can you post your vusaged.conf, configure options for the main tree, and configure options for the MySQL module? --- ./configure \ --prefix=/home/vpopmail \ --disable-roaming-users \ --enable-logging=p \ --disable-ip-alias-domains \ --disable-passwd \ --enable-clear-passwd \ --disable-domain-quotas \ --enable-auth-module=mysql \ --enable-incdir=/usr/include/mysql/ \ --enable-libdir=/usr/lib/ \ --disable-many-domains \ --enable-auth-logging \ --enable-sql-logging \ --enable-valias \ --disable-mysql-limits \ --enable-tcpserver-file=/etc/tcp.smtp --- Not using 5.5 so no mysql backend --- vusaged.conf (without comments) -- Log: Level = 1; Socket: Filename = /tmp/vusaged.sock; // Listen = 0.0.0.0:189; // Allow = 192.168.1.161 127.0.0.1; UID = vpopmail; GID = vchkpw; Client timeout = 5; // Inactivity timeout in seconds Poll timeout = 1; Detect client timeout = 4; Queue: Workers = 10; Max queue size = 1000; Polling: Use Maildir++ format = True; Directory minimum poll time = 120; Count directory entry size = True; Age Factor = 1; --- Something else is happening. What's the last entry in your ChangeLog for the version you're running? This will help me identify any source changes you may not have since you are most likely not running the trunk. 5.4.28 - Current Matt Brookings - Updated vlimits_read_vlimits_file to be much more efficient - Added vusage client API to libvpopmail - Added vusage daemon - Updated quota code to talk to vusage daemon if available - Fixed some backfill patch compilation issues - Updated maildir_to_email to support paths that end in /Maildir as well as /Maildir/ - Added LDAP valias support - Updated vusage API to return counts for both users and domains - Updated domain quota enforcement to work when using vusage - Re-enabled --enable-domainquotas (with warnings) If you want I can give you remote access to a test server where the problem can be reproduced! Sincerely, - Wouter van der Schagt !DSPAM:4a9e8b6032711366617797!
Re: [vchkpw] Vusaged segmentation fault on long names
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wouter van der Schagt wrote: > I found a bug with long domain names which crashes with a segmentation > fault when the vusaged is started. We have 1 client with a domainname of > 57 characters and although it is not the domain name listed below, it > produces the same result. I believe vpopmail supports domainnames upto > 63 characters? Or am I wrong? Is this in 5.5? What are the steps to reproduce? I added the domain as you did above, and my vusaged binary from trunk is running as expected, returning data for the long domain name. > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb2bb9b90 (LWP 29861)] > 0xb7e656c1 in mysql_free_result () from /usr/lib/libmysqlclient.so.15 > (gdb) bt > #0 0xb7e656c1 in mysql_free_result () from /usr/lib/libmysqlclient.so.15 > #1 0x08059079 in vauth_getall (domain=0x8066afe > "12345678901234567890123456789012345678901234567890123456.nl", first=1, >sortit=1) at vauth.c:737 This would seem to indicate that the issue occurred somewhere in vpopmail's vauth_getall call, or in MySQL itself. Can you post your vusaged.conf, configure options for the main tree, and configure options for the MySQL module? > I am guessing that a buffer size is too small. Increasing the > SQL_BUFF_SIZE in vauth.c to 4096 seems to work, to the extend it throws > the same error message later: I'm not sure the buffer size is really a problem here. It's set at 2048, which is plenty to handle even the longest domains and usernames. Something else is happening. What's the last entry in your ChangeLog for the version you're running? This will help me identify any source changes you may not have since you are most likely not running the trunk. - -- /* Matt BrookingsGnuPG Key FAE0672C Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqehJIACgkQIwet2/rgZyzVBACdEJaQM0lZHFiNczoJ1E2Pv7be WwcAoIv3aTNsQ3gUeQ3OJC6Akok3E3uY =OmY3 -END PGP SIGNATURE-