Failed at empty_string & print_filter

[Mercurius-Lee]

I failed to upgrade my confuse 3.2.2 to 3.3 by homebrew.

[troglobit]

Hoping there are some macOS users out there to help debug this. We need at least .log files and someone to run each failing/fauly test manually and in gdb to find the root cause.

[cardre]

I think empty_string fails I think because of the rewind using the fseek to 0 on the fmemopen file. Maybe just needs to use rewind instead? I didn't have time to verify this though.

The print_filter is crashing/seg fault because the version of macOS being used for this failure doesn't have a fmemopen implementation and its missing the external definition that happens to be at the top of the empty_string test, i.e. copy this to the top of print_filter.c

#ifndef HAVE_FMEMOPEN
extern FILE *fmemopen(void *buf, size_t size, const char *type);
#endif

[sevan]

For the empty_string test, output is

FILE:1: no such option 'Þ° ^A^Uh<8f>àr¤<90>'
----------------------------------------------
empty_string.c:37: test FAILED:
Failed test: cfg_parse_fp(cfg, f) == CFG_SUCCESS
----------------------------------------------
FAIL empty_string (exit status: 1)

I'm not seeing the issue with print_filter on OS X Tiger 10.4, running the 3.3 test suite.

[sevan]

@troglobit I can help with this, what would you like to see from gdb for the empty_string test?

[troglobit]

@troglobit I can help with this, what would you like to see from gdb for the empty_string test?

At least a backtrace, but even better would be if you could debug it back to the root cause. I have no way to take over where you leave it, or even guess what a fix could be.

[sevan]

FYI the empty_string issue is not exclusive to Darwin. I've recreated it on FreeBSD 13.2 by forcing the use of the fmemopen implementation supplied by libconfigure.
To reproduce, ./configure ac_cv_func_fmemopen=no && make check

FAIL: empty_string
==================

----------------------------------------------
empty_string.c:37: test FAILED:
Failed test: cfg_parse_fp(cfg, f) == CFG_SUCCESS
----------------------------------------------
FAIL empty_string (exit status: 1)

[troglobit]

Great! Any ideas for a fix or root cause yet?

[sevan]

Not yet. There's no back trace for empty_string since it's a single function. it's all happening in main() but I can step trough it. Still playing around to find out where it is going wrong. My guess is that one of the functions your fmemopen() implementation call has the issue. There's also a note at the bottom of funopen(3) that "The funopen() function may not be portable to systems other than BSD." and I'm wonder if that's referring to implementation details or just a heads up about availability.

[sevan]

Ok, I've narrowed it down to the second half of tests/empty_string.c, if I comment out line 35 to 40 so the second part never runs, then the empty string test passes.
Sometime the test-suite.log contains a message with garbage like FILE:2: no such option '^S¼¿ÿó<8f>å'that's fromfail_unless(cfg_parse_fp(cfg2, f) == CFG_SUCCESS);`

[sevan]

Issue is the fmemopen substitute which is a wrapper for funopen.
The funopen(3) manual on macOS states

The funopen() function associates a stream with up to four ``I/O
functions''.  Either readfn or writefn must be specified; the others can
be given as an appropriately-typed NULL pointer.  These I/O functions
will be used to read, write, seek and close the new stream.

The fmemopen substitute has a single call to funopen with read & writefn both specified. I tried to break it up so based on what operation was specified to fmemopen would be passed to funopen didn't really work and I guess would need to account for seeking as another case?

Not addressing the issue, but replacing the fmemopen call with tempfile allows tests/empty_string to pass.

--- tests/empty_string.c.orig	2024-02-07 00:08:37.000000000 +0000
+++ tests/empty_string.c	2024-02-09 00:14:12.000000000 +0000
@@ -23,7 +23,7 @@
 	cfg = cfg_init(opts, 0);
 	fail_unless(cfg_parse_buf(cfg, "string = ''") == CFG_SUCCESS);
 	fail_unless(strcmp(cfg_getstr(cfg, "string"), "") == 0);
-	f = fmemopen(buf, sizeof(buf), "w+");
+	f = tmpfile();
 	fail_unless(f != NULL);
 	cfg_print(cfg, f);
 	cfg_free(cfg);

Import a working fmemopen implementation from somewhere or don't try to use it if the host doesn't support it?

I ended up here because libftdi has a libconfuse dependency, but luckily they don't use fmemopen & cfg_parse_fp so I can sidestep the issue and put up a warning for anyone installing libconfuse with the intention of using it for other purposes that this is broken on legacy systems which lack support already.

[sevan]

Or a better approach is to stick with libconfuse 3.0 before fmemopen() usage was introduced.

[troglobit]

macOS is not an operating system I'm good at, so any help getting a pull request in to fix this problem would be great.

[sevan]

For sure, are you comfortable with FreeBSD by any chance?

[troglobit]

For sure, are you comfortable with FreeBSD by any chance?

Sure, the main problem though is finding the time. I'll see if I can find some the coming week.

[sevan]

I'll cover testing on Darwin if you can get something together, doesn't have to be in the coming week if that's a hassle.