After updating sway from 0.15.0-2 to 0.15.0-3 (along with json-c and
cryptsetup-libs that are tightly related due to dependencies/soname
bumps), I observed unability to do anything in the freshly started
sway (in both Wayland native mode and X via startx), just opening
terminal made the sway crash, returning back to virtual terminal.
Reverting said trio of packages made sway session stable again.
Symptom in case of opening terminal right after start of sway:
12/12/17 14:27:13 - [ipc-client.c:50] Unable to receive IPC response
Exiting due to signal.
urxvt: X connection to ':0' broken, unable to recover, exiting.
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
after 80 requests (80 known processed) with 0 events remaining.
Could possibly be attributed to json-c doing seemingly silly things:
After a quick look at the sway upstream issue, I don't really understand why we can't adapt to the change from int to size_t for the affected variables?
re [comment 3]:
We can, indeed, and it's likely the best way out.
With the catch that one needs to be careful about rawhide/f28
vs. older fedoras disparity.
Can you test https://koji.fedoraproject.org/koji/taskinfo?taskID=23657444 ? That's a patched version. If it works, I'll push the patch and ask upstream about it.
If they want to keep supporting older json-c versions, they could define some macro for the type depending on the json-c version, but that shouldn't be relevant for us as long as we carry a downstream patch.
Thanks, Till, tested, fix looks incomplete, still observing:
> [ipc-client.c:50] Unable to receive IPC response
Indeed, current patch only touches swaygrab (screenshot program).
Yes, I only patched the warnings from the previous build, which I guess is not enough. I will have another look tomorrow.
I'm already working on getting this fixed.
It's not as simple as changing int for size_t, though that isn't a real issue for ABI / API compatbility, since an int can at least handle numbers up to 2^31; an overflow is really unlikely, since that would only occur if the underlying json_object_array would be larger than 4 GiB, which is really far out of any reasonable use of a json_object…
I think, I found the reason… It is an embarrassing mistake the json-c developers made, when they added json_object_to_json_string_ext and made the other json_object_to_json_string functions compatibility wrappers around it…
I'm currently preparing a fix and will give you short reply, when I'm done with testing it…
Thanks, Björn, for following up on this!
Can you please try this build of json-c and see, if it fixes sway?
I suspect this as the reason for the problems sway has with it…
re [comment 11]:
Perfect, it works, thanks!
$ rpm -q sway json-c
Sorry for suspecting API compatibility mishandling issue being the
key here. This also likely means we should flip the bug on json-c.
(In reply to Jan Pokorný from comment #13)
> re [comment 11]:
> Perfect, it works, thanks!
> $ rpm -q sway json-c
> > sway-0.15.0-3.fc28.x86_64
> > json-c-0.13-4.fc28.x86_64
> Sorry for suspecting API compatibility mishandling issue being the
> key here. This also likely means we should flip the bug on json-c.
nm… I'll come up with an upstreamable patch for the size_t vs. int API / ABI thing…
It should be easily doable using sth. like: typedef __typeof__(struct array_list.length) json_al_len_t
@Jan Pokorný: Could please test those builds of json-c and sway? Are there any regressions with them?
re [comment 15]:
No regression spotted either with that combo.
As I'm using that WM on daily basis (and will be using the provided
versions till the proper update), surely I'd report anything strange.