Bugzilla Bug 88041

Muine crashes, complaining:
** (muine:16260): WARNING **: wrong maximal instruction length of instruction storer8_membase_reg (expected 9, got 10)

** ERROR **: file mini-amd64.c: line 4879 (mono_arch_output_basic_block): should not be reached
aborting...

It was working fine up until I added some new files to my library directory -- now it crashes every time I start it up -- after a few seconds (I assume when it gets to the point of importing those files)

Reproducible: Always
Steps to Reproduce:
1. Add songs to a alreadly indexed folder
2. Start up muine
3.

Actual Results:  
Crashed, with results as above

Expected Results:  
Not crashed...

Portage 2.0.51.19 (default-linux/amd64/2004.3, gcc-3.4.3-20050110,
glibc-2.3.4.20050125-r1, 2.6.12-rc1 x86_64)
=================================================================
System uname: 2.6.12-rc1 x86_64 Mobile AMD Athlon(tm) 64 Processor 2700+
Gentoo Base System version 1.6.10
Python:              dev-lang/python-2.3.5 [2.3.5 (#1, Mar 16 2005, 00:04:32)]
dev-lang/python:     2.3.5
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5
sys-devel/binutils:  2.15.92.0.2-r7
sys-devel/libtool:   1.5.14
virtual/os-headers:  2.6.8.1-r3
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CFLAGS="-march=k8 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env
/usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=k8 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox"
GENTOO_MIRRORS="http://mirror.pacific.net.au/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/overlays/mono"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X aalib acpi alsa apache2 apm avi bash-completion berkdb bitmap-fonts
bonobo bzlib cdr crypt cscope ctype cups directfb divx4linux doc dvd dvdr encode
esd evo fam fbcon flac font-server foomaticdb fortran gd gdbm gif gnome gpm
gstreamer gtk gtk2 gtkhtml imagemagick imap imlib innodb ipv6 java jp2 jpeg
junit ldap libedit libwww lzw lzw-tiff mad memlimit mime motif mozilla mp3 mpeg
msn mysql ncurses nls nntp nptl odbc oggvorbis opengl oss pam pcmcia pcre pdflib
perl php pic plotutils png pnp postgres python quicktime readline ruby samba
session shared sharedmem soap sockets spell spl sqlite ssl svg tcpd tetex tiff
tokenizer truetype truetype-fonts trusted type1-fonts unicode usb userlocales
xinerama xml2 xmms xosd xpm xrandr xv xvid zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS

- dev-lang/mono-1.1.6 (masked by: package.mask)

how comes that you use it?

@blubb: because mono-1.1.x is the only thing that actually has a JIT (and is
therefore useful) on amd64.

@Tom: Did earlier versions of mono-1.1.x let you import things ok? 1.1.5?
1.1.4? Can you get a useful backtrace when this stuff happens? (you'll need
mono compiled with USE="debug", and potentially more). Thanks.

Just thought I'd add that I have muine compiled on amd64 with mono-1.1.6 and
cannot reproduce this error. That's not to say that muine is particularly
stable though, I've had several crashes and routinely get a segfault if I try
to adjust the volume.

@Tom: also, does it seem to be linked to importing any particular files that
causes this, or any files? Does importing a sparce directory with just one
media file in it die, etc, etc?

peter,

I believe that any 1.1.x displays the same behaviour -- i tried downgrading and the bug didn't change.

It doesn't seem to be any files in particular -- I deleted my .gnome2/muine dir and cleared all the gconf flags, and it started alright -- then I imported an empty directory, and it ran fine.

Then I added one file to the the dir and restarted muine (at which point it scanned the dir) and it crashed. The choice of file does not seem to make a difference (they are all mp3).

An interesting point -- if i leave my muine dir in place (with all the covers and pre-existing imports) but clear the watched_folders flag, it still crashes. This is _very_ odd -- as it should not be attempting to add any files in this case.

So perhaps it might not be the act of importing, but maybe could be something else that importing sets off. But I used it for a week or two before this behaviour started, and it adding new files to my lib that set it off.

Anyway I will hopefully be able to find out where in the code it is dying and confirm that all mono 1.1.x display the same problem. I will get back to you

Created an attachment (id=56053) [edit]
patch-1.1.6-r43200

Tom: okay, still waiting to hear from you on more info.

Until then, I managed to dig this patch up after finding
http://bugzilla.ximian.com/show_bug.cgi?id=74103 on the Ximian bugzilla. This
is the patch that Zoltan commited to fix that bug, which seems to be the same
one you're running into. Patch to the 1.1.6 ebuild which applies this mono
patch to follow.

Created an attachment (id=56054) [edit]
Diff to the 1.1.6 ebuild

Ok, here's a patch to the 1.1.6 ebuild that applies the fix for amd64. Can you
please apply this to the 1.1.6 ebuild in portage, drop the previously attached
patch into the files/ dir, and re-emerge mono? Let me know how it goes. Thanks.

I applied the patch, all went smoothly and it seems to have fixed the problem.

Mind you this is 2 minutes later. I'll let you know if I have any more troubles.

Thanks heaps.

Tom: Ok, if you could just report back after a day or two of usage if the
problem still doesn't reproduce itself, i'll get this commited in 1.1.6-r1.
Thanks.

Since tom has not responded, I'll comment here. I was able to reprodoce this
crash with muine-0.8.2 (had not realised that that was the version under
discussion). After applying this patch muine seems to be remarkably stable ;-)
I've been running it quite extensively for the past couple of days and have not
had a single crash!

On a side note, any plans to bring mono-1.1.* out of package.mask? or will you
wait for 1.2.0 to be released? I note that the mono guys "consider Mono 1.1.6
stable enough to recommend it for all users".

Ok, i've just commited 1.1.6-r1 that includes this patch. Marking this FIXED,
but Tom, if you are still having problems feel free to re-open this bug.

As for getting 1.1.6 out of package.mask, an excerpt fro my latest blog post
(http://www.tenslashsix.com/index.php?p=60):
"Someone commented on my blog about when mono-1.1.x will be out of
package.mask, especially since upstream is pushing this is 

Ok, i've just commited 1.1.6-r1 that includes this patch. Marking this FIXED,
but Tom, if you are still having problems feel free to re-open this bug.

As for getting 1.1.6 out of package.mask, an excerpt fro my latest blog post
(http://www.tenslashsix.com/index.php?p=60):
"Someone commented on my blog about when mono-1.1.x will be out of
package.mask, especially since upstream is pushing this is “stable enough for
regular users". Indeed, mono-1.1.x is that stable, it actually makes nant
compile, uses less memory, mcs the compiler is stricter/better, etc.
Unfortunately, upstream doesn’t take into account fixing all the applications
that the stricter compiler/runtime engine breaks because these apps made
assumptions previously about the way mono (wrongly in most cases) behaved. The
big problem child being monodevelop-0.5* which just doesn’t like mono-1.1.x.
Fortunately 0.6 is in the tree, but that is still package.masked because it
depends on the gtk-sharp-1.9.x stuff, which is less than ready “enough for
regular users". So yes, I’m itching to get mono-1.1.x out of package.mask, but
before I do that, monodevelop-0.6 and gtk-sharp-1.9.x must be out too, and that
is what’s gonna be at least a while longer. All in due time."

so... we're waiting on that for the most part.

Peter,

As yet I've experienced no further problems, so I'd say that yes the patch does indeed fix the problem.

Thanks again.