Opened 3 years ago

Closed 3 years ago

#21416 closed defect (duplicate)

util/fgets_eagain test failure on FreeBSD

Reported by: ahf Owned by: ahf
Priority: Low Milestone:
Component: Core Tor/Tor Version:
Severity: Minor Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The util/fgets_again test currently fails on FreeBSD with the following error:

$ ./src/test/test util/fgets_eagain
util/fgets_eagain: 
  FAIL src/test/test_util.c:3969: assert(retptr OP_EQ buf): 0x0 vs 0x7efe49dea1f0
  [fgets_eagain FAILED]
1/1 TESTS FAILED. (0 skipped)

This causes the FreeBSD build-bot to report failure on every commit.

Child Tickets

Attachments (1)

test_eagain.c (967 bytes) - added by ahf 3 years ago.
Test case lifted out of Tor.

Download all attachments as: .zip

Change History (4)

Changed 3 years ago by ahf

Attachment: test_eagain.c added

Test case lifted out of Tor.

comment:1 Changed 3 years ago by ahf

I've run the attached test case on a couple of targets thanks to some help by some friends on IRC.

Linux with glibc:

feof()   = 0
ferror() = 1
retptr   = 0x7ffcefd02030

Linux with musl-libc (Thanks to Somasis):

feof()   = 0
ferror() = 1
retptr   = 0

FreeBSD:

feof()   = 0
ferror() = 1
retptr   = 0x0

OpenBSD (Thanks to Kramse):

feof()   = 0
ferror() = 1
retptr   = 0x7f7ffffbfd40

OS X

feof()   = 0
ferror() = 1
retptr   = 0x7fff5d37d710

It seems like the assumption that the returned pointer value is always the same as the input buffer in this case is incorrect for some of our supported operating systems.

Should we consider making a tor_fgets in our compatibility layer, which checks for ferror(file) == 1 and errno == EAGAIN and in that case returns NULL?

comment:2 Changed 3 years ago by ahf

Error correction: I meant to return the pointer to the input buffer and not NULL.

comment:3 Changed 3 years ago by cypherpunks

Resolution: duplicate
Status: newclosed

This is a duplicate of #20988.

Note: See TracTickets for help on using tickets.