SIGBUS on wl_shm clients (Re: Newest git version of Wayland is even worse)

[Bill Spitzak]

Another question: I thought XDG_RUNTIME_DIR was being used for the locks 
and sockets and other status indicators. I expected large shm buffers to 
go to some more-standard place (though I don't know what the Linux 
standard is). I certainly was suprised to find that XDG_RUNTIME_DIR has 
such a major effect on behavior.

What is the standard location that a Linux desktop application that 
wants to allocate a large shm buffer use? Perhaps Wayland apps should 
use that, too.

On 12/09/2012 11:55 AM, Pekka Paalanen wrote:
> On Sat, 8 Dec 2012 17:52:46 -0500
> darxus at chaosreigns.com wrote:
>
>> On 12/08, Bill Spitzak wrote:
>>> On 12/08/2012 12:23 AM, Pekka Paalanen wrote:
>>>
>>>> FWIW, I have seen a bus error (SIGBUS) before. One way to trigger
>>>> it is to run out of space on the tmpfs, where your XDG_RUNTIME_DIR
>>>> points to. Maybe you should check that?
>>>>
>>>> I think it needs at least 20-30 MB, to not run out too soon with
>>>> shm clients, and the more the better. Of course depends quite a lot
>>>> on whether toytoolkit is mainly using shm or EGL buffers. If
>>>> you are still on proprietary drivers, it is definitely shm buffers.
>>>
>>> Indeed that was it. I had XDG_RUNTIME_DIR set to /var/lock which
>>> only has 5M on it. Changing it to /var/tmp makes things work again.
>>
>> Is there a way to get a better error message for that?  Or maybe throw a
>> warning at startup?
>
> Not really, unless you start checking the free space of the mount
> where the XDG_RUNTIME_DIR happens to be on, and have some arbitrary
> threshold. Or catch SIGBUS, and print an error saying that please
> check free space.
>
> These should be in all the clients, and it is quite ugly anyway.
> Libwayland-client certainly should not add signal handlers on its
> own, and we cannot really come up with a good number for the free
> space, either. Whatever the number, you may still hit the limit, or
> then the number is ridiculous.
>
> Since it is a signal, instead of, say, ftruncate() failing, there's
> very little we can sanely do, TTBOMK.
>
>
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>