Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

investigate swprintf call failure (#37735) #37912

Merged
merged 2 commits into from
Oct 19, 2020
Merged

investigate swprintf call failure (#37735) #37912

merged 2 commits into from
Oct 19, 2020

Conversation

vtjnash
Copy link
Member

@vtjnash vtjnash commented Oct 6, 2020

No description provided.

@vtjnash
Copy link
Member Author

vtjnash commented Oct 7, 2020

That's odd:

ERRORS
    The printf() family of functions may fail if:
     [EILSEQ]           An invalid wide character code was encountered.

@vtjnash
Copy link
Member Author

vtjnash commented Oct 7, 2020

Hm, apparently this might be a known bug in FreeBSD (that %ls doesn't follow the posix spec)? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=114578

@vtjnash
Copy link
Member Author

vtjnash commented Oct 7, 2020

FWIW, it appears that tabularasa_freebsd-x86_64-openstack_2 has always failed, and tabularasa_freebsd-x86_64-openstack_3 has always succeeded at this test, so I suspect a configuration issue compounded by that FreeBSD bug. (this current CI run will hopefully help clarify that)

https://build.julialang.org/#/builders/33/builds/4490 says we have on the broken bot:

      From worker 4:	LANG=
      From worker 4:	LC_CTYPE="C"
      From worker 4:	LC_COLLATE="C"
      From worker 4:	LC_TIME="C"
      From worker 4:	LC_NUMERIC="C"
      From worker 4:	LC_MONETARY="C"
      From worker 4:	LC_MESSAGES="C"
      From worker 4:	LC_ALL=

and on the working bot:

      From worker 4:	LANG=
      From worker 4:	LC_CTYPE="en_US.UTF-8"
      From worker 4:	LC_COLLATE="en_US.UTF-8"
      From worker 4:	LC_TIME="en_US.UTF-8"
      From worker 4:	LC_NUMERIC="en_US.UTF-8"
      From worker 4:	LC_MONETARY="en_US.UTF-8"
      From worker 4:	LC_MESSAGES="en_US.UTF-8"
      From worker 4:	LC_ALL=en_US.UTF-8

@vtjnash
Copy link
Member Author

vtjnash commented Oct 9, 2020

It appears that the macOS libc also inherited the same issue from BSD:

~/julia/test$ LANG= make ccall
    JULIA test/ccall
Test  (Worker) | Time (s) | GC (s) | GC % | Alloc (MB) | RSS (MB)
ccall      (1) |        started at 2020-10-09T14:32:01.183
ccall      (1) |         failed at 2020-10-09T14:32:41.973
Error During Test at /Users/jameson/julia/test/ccall.jl:1713
  Got exception outside of a @test
  InexactError: check_top_bit(UInt64, -1)
  Stacktrace:
    [1] throw_inexacterror(f::Symbol, #unused#::Type{UInt64}, val::Int32)
      @ Core ./boot.jl:602

@vtjnash vtjnash marked this pull request as ready for review October 9, 2020 22:51
@vtjnash vtjnash requested a review from JeffBezanson October 9, 2020 22:51
@vtjnash
Copy link
Member Author

vtjnash commented Oct 10, 2020

Ah, sometimes it seems you just can't win. Looks like the tabularasa_linux-x86_64-nanosoldier2_1 has utf-8 support disabled?? and thus the warning message I added for that situation then causes some of the tests to fail.

@vtjnash vtjnash force-pushed the jn/37735 branch 2 times, most recently from 4c8304f to c7ee448 Compare October 15, 2020 17:38
Some basic functionality in libc (such as printf) might be broken if the
string encoding is not matching our Cstring expectations.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant