Seg fault in make check #15

Closed
opened 8 months ago by brodygoat · 7 comments

I use your AUR PKGBUILD. Obviously the executable doesn't have debugging symbols, but I can figure out how to compile with them if you need.

Running bc errors..../tests/errors.sh: line 101: 107555 Done                    printf '%s\n' "$line"
     107556 Segmentation fault      (core dumped) | "$exe" "$@" "$options" 2> "$out" > /dev/null

bc crashed (139) on test:

    j(1,2,3)
make: *** [Makefile:349: test_bc_error_lines] Error 139
I use your AUR PKGBUILD. Obviously the executable doesn't have debugging symbols, but I can figure out how to compile with them if you need. ``` Running bc errors..../tests/errors.sh: line 101: 107555 Done printf '%s\n' "$line" 107556 Segmentation fault (core dumped) | "$exe" "$@" "$options" 2> "$out" > /dev/null bc crashed (139) on test: j(1,2,3) make: *** [Makefile:349: test_bc_error_lines] Error 139 ```
Owner

Yeah, that is not good, but I think I have an idea of where the problem is.

First, what locale are you using? If it's not the C locale, I suspect the problem is because I changed error messages.

If so, could you build my bc by hand and install it, then run make check? If it passes, then the problem is because the test suite is running against the installed locale files rather than the new locale files (I had to add some error messages).

Honestly, though, I don't know how to fix the PKGBUILD if it is using the old locale files. Maybe I need to force using the C locale during make check.

Yeah, that is not good, but I think I have an idea of where the problem is. First, what locale are you using? If it's not the C locale, I suspect the problem is because I changed error messages. If so, could you build my bc by hand and install it, then run `make check`? If it passes, then the problem is because the test suite is running against the installed locale files rather than the new locale files (I had to add some error messages). Honestly, though, I don't know how to fix the PKGBUILD if it is using the old locale files. Maybe I need to force using the C locale during `make check`.

@brodygoat, I have edited the PKGBUILD to set LANG=C and LC_ALL=C. Could you see if this solves your problem?

@brodygoat, I have edited the `PKGBUILD` to set `LANG=C` and `LC_ALL=C`. Could you see if this solves your problem?
Poster

Oh I didn't realize I wouldn't get email notifications. Yeah, that worked @kseistrup. That seems a reasonable change in the PKGBUILD.

So your changes don't work with unicode, @gavin?

Also I didn't realize someone else had taken up the AUR package maintainer role. I would have submitted this there first.

Oh I didn't realize I wouldn't get email notifications. Yeah, that worked @kseistrup. That seems a reasonable change in the PKGBUILD. So your changes don't work with unicode, @gavin? Also I didn't realize someone else had taken up the AUR package maintainer role. I would have submitted this there first.
Owner

My changes do work with Unicode. However, POSIX locales are fundamentally broken, and that is where the issue is.

In the development manual Locales section, I talk about how POSIX locales use $NLSPATH to find locales. This is the only way to access locale data for a program such as bc, so it means that the non-installed bc being tested in the package always tries to access the installed locale files.

This is generally not a problem, as the locale files do not change often; in fact, they only change when I need to add error messages.

And even that would not be a problem if the error messages were not used as format strings for printf().

And even that would not be a problem if the error messages used the same format specifiers.

However, they do not. Some error messages use format specifiers (they need extra data), and some do not. This means that when error messages get added, the installed locales may have an error message with a format specifier that expects extra arguments, but the non-installed locale does not. So when the bc is under test, it is assuming that its locale is installed. In this case, that was not true, and printf() tried to grab a function argument that wasn't there. Hence, you got a segfault.

However, once you actually install bc, you will be able to use Unicode without issue because the package will have installed the new locales along with the newly-installed bc, and printf() will be given the correct error message, which means that it won't try to pull in arguments that are not there.

Does that make sense?

My changes do work with Unicode. However, POSIX locales are fundamentally broken, and that is where the issue is. In the [development manual Locales section][1], I talk about how POSIX locales use `$NLSPATH` to find locales. This is the only way to access locale data for a program such as `bc`, so it means that the *non-installed* `bc` being tested in the package always tries to access the *installed* locale files. This is generally not a problem, as the locale files do not change often; in fact, they only change when I need to add error messages. And even that would not be a problem if the error messages were not used as format strings for `printf()`. And even *that* would not be a problem if the error messages used the same format specifiers. However, they do not. Some error messages use format specifiers (they need extra data), and some do not. This means that when error messages get added, the installed locales may have an error message with a format specifier that expects extra arguments, but the non-installed locale does not. So when the `bc` is under test, it is assuming that its locale is installed. In this case, that was not true, and `printf()` tried to grab a function argument that wasn't there. Hence, you got a segfault. However, once you actually install `bc`, you will be able to use Unicode without issue because the package will have installed the new locales along with the newly-installed `bc`, and `printf()` will be given the correct error message, which means that it won't try to pull in arguments that are not there. Does that make sense? [1]: https://git.yzena.com/gavin/bc/src/branch/master/manuals/development.md#locales-1

@brodygoat I'm glad it solved your problem.

@brodygoat I'm glad it solved your problem.

@brodygoat PS: I have steeped in as co-maintainer of the AUR package since @gavin doesn't use ArchLinux.

@brodygoat PS: I have steeped in as co-maintainer of the AUR package since @gavin doesn't use ArchLinux.
Owner

I'm going to close this for inactivity and because the problem seems to be fixed.

I'm going to close this for inactivity and because the problem seems to be fixed.
gavin closed this issue 8 months ago
Sign in to join this conversation.
No Label
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.