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 attachment 56053 [details, diff] 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 attachment 56054 [details, diff] 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 doesnt 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 doesnt 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, Im 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 whats 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.
