2.5.0-beta1 crashes client while resizing xterm

Submitted by patataj on Sat, 2013-10-19 04:42

Forums:

While resizing xterm mocp client crashes with

FATAL_ERROR: select() failed: Exec format error

I don't know C language so idk what's causing the error as well.
This solves problem for me but most of the time it doesn't render interface correctly after changing the window size (I need to keep resizing as long it will render properly).
I guess it's better than a crash

--- interface.c 2013-10-19 06:15:18.819243399 +0200
+++ interface.c.patch 2013-10-19 06:16:52.731630212 +0200
@@ -3228,7 +3228,7 @@

if (ret == 0)
do_silent_seek ();
- else if (ret == -1 && !want_quit && errno != EINTR)
+ else if (ret == -1 && !want_quit && errno != EINTR && !want_resize)
interface_fatal ("select() failed: %s",
strerror(errno));

Tested on Debian Sid with awesome v3.5.1

jcf

Sat, 2013-10-19 07:30

I keep reaching a conclusion I don't want to reach on this, and that's that select(2) is returning an errno of ENOEXEC which is undocumented and doesn't make sense in this context. But it's the only explanation I can see at present and it is what MOC's reporting.

kotzenhuber

Tue, 2013-11-19 16:55

Hi there. Mocp client crashes when maximizing terminal.
My setup is
Fedora 3.9.5-301.fc19.i686

with self-compiled

moc 2.4.4 Build: Nov 1 2013 04:30:42
Compiled with: OSS ALSA DEBUG

I'm not much of an expert, so it might as well be something to do with my compilation (I remember facing some incompatibilities with libmad/g++ iirc).

When I strace the client and resize, it exits this way:


fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7722000
write(1, "\n", 1
) = 1
write(2, "\nFATAL_ERROR: select() failed: E"..., 50
FATAL_ERROR: select() failed: Exec format error

) = 50
exit_group(2) = ?
+++ exited with 2 +++

http://pastebin.com/qS8zVd6K

I'm using rxvt-unicode fedora binary.

jcf

Tue, 2013-11-19 19:54

Using strace(1) was a good move, but unfortunately the output you posted in pastebin got a little corrupted.

Could you rerun the test using the strace(1) options '-o tr -ff' which will create a separate tr.* file for each of the client and server. Edit these files to retain only the last hundred lines or so to reduce size, then create a compressed tarball (tar czf moc-test.tar.gz tr.*) and e-mail it to mocmaint.

Also, since you're building from source you should probably grab the 2.5.0-beta1 tarball to see if the problem still exists (though I suspect it will).

kotzenhuber

Tue, 2013-11-19 21:18

I've sent an email.
Strange enough, I seem to remember that resizing didn't cause any problem until recently. I've set up this system just some days ago and haven't used it much, but afair, after first compile and install, I have probably resized one or the other mocp-terminal. So it may very well be a misconfiguration on my system and not a bug ;-). Cheers.

jcf

Tue, 2013-11-19 23:04

Having examined the strace(1) output, it seems to me that we're being mislead by MOC 2.4.4. The code which is misleading us was fixed in SVN r2289 which is included in 2.5.0-beta1, so trying again with that release will at least give us the correct error information and maybe even resolve the problem if it's being falsely reported.

kotzenhuber

Wed, 2013-11-20 06:57

Hi there. Now that I've compiled 2.5.0-beta1 and everything works ok, I come to notice that the thread title indeed says explicitly "2.5.0-beta1".
Um, sorry for impulse posting and spamming into this once neat and clean bug report :-/. I got taken away by the "resize" subject. Seemed so obviously the same.

jcf

Wed, 2013-11-20 07:28

Your contribution has been valuable exactly because it was so like the original report; so much so that I now believe user "patataj" is not actually on the version he reported, and re-examining his patch supports that. It would also explain why I kept reaching such an unpalatable conclusion. If we don't hear back from him I think it's safe to close this problem as already fixed.

Even though 2.5.0-beta1 is listed as a development release, it's still much cleaner than the current 2.4.4 stable release.

patataj

Mon, 2014-01-27 12:56

I have no idea how I managed to grab a 2.4.4 source instead of 2.5 but I suppose it was a long and busy night.
Obviously I've compiled 2.4.4.

jcf

Tue, 2014-01-28 08:54

... as the dalek said climbing off the dustbin.

Anyway, can we assume it's all sweet for you now?

patataj

Wed, 2014-01-29 22:36

I think so, yes