| Summary: | Muine (mono 1.1.6) dies when it tries to import new files | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tom Coleman <tom> |
| Component: | New packages | Assignee: | dotnet project <dotnet> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | amd64 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
patch-1.1.6-r43200
Diff to the 1.1.6 ebuild |
||
|
Description
Tom Coleman
2005-04-05 08:19:03 UTC
- 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. |
