binkd segfault

[andrew clarke]

Using the latest version of BinkD from CVS, attempting to use a config file that doesn't exist causes a segfault:

$ ./binkd -v
Binkd 1.1a-16 (Oct 25 2012 05:34:30/Linux)

$ ./binkd x
05:39 [32023] <command line>: line 0: error in configuration files
Segmentation fault

Segfault also occurs in FreeBSD.

[Tommi Koivula]

25 Oct 12 05:41, you wrote to all:

ac> Using the latest version of BinkD from CVS, attempting to use a config
ac> file that doesn't exist causes a segfault:

ac> $ ./binkd -v
ac> Binkd 1.1a-16 (Oct 25 2012 05:34:30/Linux)

ac> $ ./binkd x
ac> 05:39 [32023] <command line>: line 0: error in configuration files
ac> Segmentation fault

ac> Segfault also occurs in FreeBSD.

C:\fido\BinkD>binkd.exe -v
Binkd 1.1a-16 (Oct 24 2012 21:52:03/CYGWIN_NT-6.1)

C:\fido\BinkD>binkd.exe x
21:53 416 <command line>: line 0: error in configuration files
? 21:53 416 cannot open x: No such file or directory
! 21:53 416 error in configuration, aborting

Nothing wrong with the cygwin version.

'Tommi

[andrew clarke]

25 Oct 12 05:41, I wrote to all:

ac> Using the latest version of BinkD from CVS, attempting to use a config
ac> file that doesn't exist causes a segfault:

ac> $ ./binkd -v
ac> Binkd 1.1a-16 (Oct 25 2012 05:34:30/Linux)

ac> $ ./binkd x
ac> 05:39 [32023] <command line>: line 0: error in configuration files
ac> Segmentation fault

ac> Segfault also occurs in FreeBSD.

Update: For some reason the crash only occurs on 64-bit builds.

No segfault if I build with 'gcc -m32' on either Linux or FreeBSD.

[Andre Grueneberg]

Hi andrew

andrew clarke schrieb:

ac>> $ ./binkd x
ac>> 05:39 [32023] <command line>: line 0: error in configuration files
ac>> Segmentation fault
ac> No segfault if I build with 'gcc -m32' on either Linux or FreeBSD.

Indeed, this leads to the cause. The problem is in the va_arg handling in
readcfg.c/ConfigError() function. It treats all parameters as int, whereas
usually we're passing 'char *'. Unfortunately it's not always the case, so it
feels like the current handling of arguments is flawed and just doesn't work on
64bit.

I'll need some more minutes to understand what's going on and what are the
intentions. :)

CU Andre E-Mail: ***@grueneberg.de

[andrew clarke]

25 Oct 12 22:30, you wrote to me:

AG> Indeed, this leads to the cause. The problem is in the va_arg handling
AG> in readcfg.c/ConfigError() function. It treats all parameters as int,
AG> whereas usually we're passing 'char *'. Unfortunately it's not always
AG> the case, so it feels like the current handling of arguments is flawed
AG> and just doesn't work on 64bit.

Yes, I saw the va_arg code in readcfg.c but didn't really understand what it
was doing. Then I noticed that code wasn't in the zipfile for binkd 0.9.9, so
it's a recent change, thus shouldn't be too difficult for the author(s) to fix.

AG> I'll need some more minutes to understand what's going on and what are
AG> the intentions. :)

That's OK :)

AG> --- timEd/Linux 1.11.b6
AG> * Origin: Testing timed/Linux (2:2411/525)

Incidentally you might be interested in my recent post about timEd in the
ARTWARE echo re: message base corruption in the Linux/BSD port.

[Andre Grueneberg]

Hi andrew

andrew clarke schrieb:

AG>> Indeed, this leads to the cause. The problem is in the va_arg handling
AG>> in readcfg.c/ConfigError() function. It treats all parameters as int,
AG>> whereas usually we're passing 'char *'. Unfortunately it's not always
AG>> the case, so it feels like the current handling of arguments is flawed
AG>> and just doesn't work on 64bit.
ac> Yes, I saw the va_arg code in readcfg.c but didn't really
ac> understand what it was doing. Then I noticed that code wasn't in
ac> the zipfile for binkd 0.9.9, so it's a recent change, thus
ac> shouldn't be too difficult for the author(s) to fix.

It's fixed in 1.1-a17. Could you please test the correction in your test
environments. If this is successful, I'll backport the correction to the 1.0
branch.

AG>> * Origin: Testing timed/Linux (2:2411/525)
ac> Incidentally you might be interested in my recent post about timEd
ac> in the ARTWARE echo re: message base corruption in the Linux/BSD
ac> port.

Indeed, I read it. Still I don't want to move to GoldEd ... unless it has so
much improved in the last 5 years?! I was really relieved to get back timEd on
Unix then. OTOH timEd is about the only thing stopping me from moving to UTF-8.
:/

CU Andre E-Mail: ***@grueneberg.de

[andrew clarke]

28 Oct 12 22:33, you wrote to me:

AG> It's fixed in 1.1-a17. Could you please test the correction in your
AG> test environments. If this is successful, I'll backport the correction
AG> to the 1.0 branch.

Looks good in 64-bit FreeBSD & Linux. 32-bit seems OK too.

FWIW, a couple of unrelated compiler warnings in the Linux build (gcc 4.4.3 on
Ubuntu 10.04):

protocol.c: In function 'protocol':
protocol.c:3863: warning: dereferencing pointer 'peer_name.205' does break
strict-aliasing rules
protocol.c:3863: note: initialized from here
run.c: In function 'run3':
run.c:133: warning: ignoring return value of 'pipe', declared with attribute
warn_unused_result
run.c:134: warning: ignoring return value of 'pipe', declared with attribute
warn_unused_result
run.c:135: warning: ignoring return value of 'pipe', declared with attribute
warn_unused_result

ac>> Incidentally you might be interested in my recent post about
ac>> timEd in the ARTWARE echo re: message base corruption in the
ac>> Linux/BSD port.

AG> Indeed, I read it. Still I don't want to move to GoldEd ... unless it
AG> has so much improved in the last 5 years?!

Not sure. What issues did you have? (Maybe we should move this to GOLDED.)

AG> I was really relieved toget back timEd on Unix then. OTOH timEd is
AG> about the only thingstopping me from moving to UTF-8. :/

Feel free to add UTF-8 support ;-)

[Andre Grueneberg]

Hi andrew

andrew clarke schrieb:

ac> protocol.c:3863: warning: dereferencing pointer 'peer_name.205'
ac> does break strict-aliasing rules

Hmm, I wonder why struct sockaddr_storage and struct sockaddr shouldn't be
compatible with each other wrt its *_family member?!

ac> run.c: In function 'run3':
ac> run.c:133: warning: ignoring return value of 'pipe', declared with
ac> attribute warn_unused_result
ac> run.c:134: warning: ignoring return value of 'pipe', declared with
ac> attribute warn_unused_result
ac> run.c:135: warning: ignoring return value of 'pipe', declared with
ac> attribute warn_unused_result

This sounds like a good idea ... if pipe() fails, the results might be strange.

AG>> I was really relieved toget back timEd on Unix then. OTOH timEd is
AG>> about the only thingstopping me from moving to UTF-8. :/
ac> Feel free to add UTF-8 support ;-)

Ah, well ...

CU Andre E-Mail: ***@grueneberg.de