Bug 1525020 - sway-0.15.0-3.fc28.x86_64 unusable
Summary: sway-0.15.0-3.fc28.x86_64 unusable
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: sway
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Till Hofmann
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-12 13:21 UTC by Jan Pokorný [poki]
Modified: 2017-12-14 22:22 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-13 21:25:55 UTC


Attachments (Terms of Use)

Description Jan Pokorný [poki] 2017-12-12 13:21:50 UTC
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.

Comment 1 Jan Pokorný [poki] 2017-12-12 13:31:28 UTC
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.

Comment 2 Jan Pokorný [poki] 2017-12-12 17:28:22 UTC
Could possibly be attributed to json-c doing seemingly silly things:
https://github.com/swaywm/sway/pull/1438

Comment 3 Till Hofmann 2017-12-12 17:50:55 UTC
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?

Comment 4 Jan Pokorný [poki] 2017-12-12 17:57:04 UTC
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.

Comment 5 Till Hofmann 2017-12-12 18:36:19 UTC
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.

Comment 6 Jan Pokorný [poki] 2017-12-12 19:22:28 UTC
Thanks, Till, tested, fix looks incomplete, still observing:
> [ipc-client.c:50] Unable to receive IPC response

Comment 7 Jan Pokorný [poki] 2017-12-12 19:27:59 UTC
Indeed, current patch only touches swaygrab (screenshot program).

Comment 8 Till Hofmann 2017-12-12 22:38:55 UTC
Yes, I only patched the warnings from the previous build, which I guess is not enough. I will have another look tomorrow.

Comment 9 Björn 'besser82' Esser 2017-12-13 15:03:44 UTC
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…

Comment 10 Jan Pokorný [poki] 2017-12-13 15:58:51 UTC
Thanks, Björn, for following up on this!

Comment 11 Björn 'besser82' Esser 2017-12-13 20:12:10 UTC
Can you please try this build of json-c and see, if it fixes sway?

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

Comment 12 Björn 'besser82' Esser 2017-12-13 20:23:24 UTC
I suspect this as the reason for the problems sway has with it…

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

Comment 13 Jan Pokorný [poki] 2017-12-13 21:12:58 UTC
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.

Comment 14 Björn 'besser82' Esser 2017-12-13 21:25:07 UTC
(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

Comment 15 Björn 'besser82' Esser 2017-12-14 18:25:50 UTC
@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

Comment 16 Jan Pokorný [poki] 2017-12-14 22:22:13 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.