Bug 1525020

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:
https://github.com/swaywm/sway/pull/1438

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?

See:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QDS2AAB2TJMDBRTFDLI3ZOAMQI4HDKFO/

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?

https://koji.fedoraproject.org/koji/taskinfo?taskID=23670916

I suspect this as the reason for the problems sway has with it…

https://github.com/json-c/json-c/pull/389

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.

(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?

https://koji.fedoraproject.org/koji/taskinfo?taskID=23684695

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.