aMule Forum
English => en_Bugs => Topic started by: Typhoid on April 30, 2006, 09:12:18 AM
-
aMule 2.1.1, Intel Mac Mini Duo, Mac OS 10.4.6
When there are multiple tabs in the Search section, selecting and right-clicking on tabs does not work properly. When I right-click on a tab, it selects the tab that is to the left of the one that I right-clicked on.
So if there are multiple tabs and I right-click on the second tab, then the first tab is selected. If I right-click on the third tab, then the second tab is selected, and so on.
-
It seems I owe the wxWidgets folks an apology. On other threads reporting this bug, I blamed it on them re-breaking something I fixed. It turns out it was because they applied the fix I suggested -- their fix plus the workaround I put in our code doubled up and overcompensated. I have submitted the fix to our code. The next Mac release won't have this bug.
Thanks for you report.
-
I just installed version 2.1.2 universal binary for 10.4 Tiger, and it appears to still have the tab selection issue.
-
Ken is a liar obviously.
-
Originally posted by Kry
Ken is a liar obviously.
Indeed.
Several things happened:
- I committed to CVS but didn't merge to the release branch, so it didn't get into 2.1.2
- My commit was broken, anyway
- None of my fellow developers noticed either of the above, which makes it ALL THEIR FAULT! :]
- Oddly, the compiler didn't complain about my broken code, either
I'll try to fix this later today.
-
When there are multiple tabs in the Search section, selecting and right-clicking on tabs does not work properly. When I right-click on a tab, it selects the tab that is to the left of the one that I right-clicked on.
So if there are multiple tabs and I right-click on the second tab, then the first tab is selected. If I right-click on the third tab, then the second tab is selected, and so on.
I installed amule 2.1.3 Universal Binary version for Mac OS Tiger, and right-clicking on a tab now highlights the correct tab. But now the context menu is missing from the tabs.
-
@Typhoid:
I merged your new thread with this existing one.
Seems really weird that the context menu is not showing and that the correct tab is selected. On my machine, the wrong tab is still selected in a current CVS build of aMule. So my suspicion is that your right-clicking somehow generates a left click. Could you try doing a control-click on a tab?
-
I tried both control-clicking and right clicking on a tab in the Search results. In each case, the correct tab is selected but there is no context menu. I am running Mac OS 10.4.6 on an Intel Mac Mini.
-
Weird. Unfortunately I can't test this on 10.4, because my Tiger machine is on a network that filters ed2k packets. Could anybody else test the right-clicking on tabs with aMule 2.1.3 on 10.4?
-
Ok, with current amule CVS on OS X 10.3 I can reproduce the problem (no context menu). In addition, right-click and contol-click don't even select a search tab. There is, however, no problem with the category tabs in the download window.
Looks like we are dealing with a truth challenged serial offender here... ;)
-
lionel, what wx are you using for these builds? I think the problem lies there. One of the checks I put into the source code checks for wx version 2.7.0 or better. Now, obviously wx 2.7.0 hasn't been released, but the wx part of the fix is incorporated into wx-cvs and that's the version reflected there. So, my check is appropriate for the wx that will be released as 2.7.0 (and any wx-cvs after a certain point). However, if you're using a wx-cvs that's post-2.6.3 but not as recent as when the change was put into wx, you'll confuse the issue. The check I put in the code has no way to distinguish wx-cvs before the fix from wx-cvs after.
Try with wx 2.6.3 and/or current wx-cvs and see if the problem persists.
-
I am using wx cvs from early March for all aMule builds, because I have not been able to compile a working aMule with a more recent version of wx (see here (http://forum.amule.org/thread.php?threadid=9974)). That version is, however, already identified as 2.7.0, but it is probably pre-fix then.
I am making another attempt at compiling aMule with current wx as we speak (last attempt was 6 weeks or so ago). Maybe they fixed the issue by now. If not, it would be great if one of you guys could take a look at it. :)
-
Problem is gone as promised when using current wx CVS. :)
-
hi there,
i run mac os 10.4.6 with amule 2.1.3. which i only recently started running (10 days ago, before i was running 2.0.1)
when i rightclick a tab nothing happens ( until 5 days ago i had the other problem, rightclicking selected the previous tab...),there appears to be no menu in the tabs anymore...!
i posted this question in another thread already(forum max OSX_tabs_bug) as a reply to someone with a similar question, i hope i'm not confusing anyone.....
any help is appreciated big time
-
Here's the problem:
In order for ken's tab fix to work, aMule needs to be built against a more recent version of wx CVS. Unfortunately, when aMule is built against recent wx CVS, it crashes reliably after a few minutes here.
So until someone fixes that issue in wx (*wink* *wink*), you won't be able to right-click on search tabs and close them. :(
-
I should point out that my fix works properly against wx2.6.3, too. It was only certain versions of wx-cvs (those that were marked as version 2.7.0 but didn't yet contain the fix from their side) that had a problem with my patch. Is there a reason you don't build against wx2.6.3, lionel77? It is, after all, the recommended stable release. (That's an honest question, not a criticism. :))
-
You're right, ken, I should try building against 2.6.3. I had mentally marked 2.6.3 as broken, because it was not possible to get a working aMule binary with it, but that was before your recent fix for that issue. So I'll give 2.6.3 a shot and see how far I'll get with it.
-
Ok, so I tried building aMule CVS against wx 2.6.3 now and all I can say is "recommended stable release" my ass... ;)
Interestingly, the resulting binary also contains the 'long long unsigned' bug (e.g., wrong display of times on statistics page, frequent crashes), even though I thought that change was made later in wx CVS. But on the bright side, the tab bug is indeed fixed in 2.6.3. ;)
I just double-checked that the long long unsigned bug does not show with current aMule CVS when built against wx CVS from March 7 (that's the wx install that I've used for the past couple month, for which the tab fix does not work) and indeed it does not.
I guess it could start another compile-athlon to hopefully find an older wx CVS version in which your fix is already committed but the long long unsigned bug is not introduced yet. That would however only be a temporary solution. Eventually, we will need to get this bug fixed in wx.
EDIT:
I just saw that Kry wants to to get 2.1.4 out soon. Is there any way we can get this wx bug fixed before? I would really hate to release a second stable version of aMule in which the tab thing is broken...
-
Which is nice if you tell me when it arised, as I can check the wx changes from that date.
-
Originally posted by Kry
Which is nice if you tell me when it arised, as I can check the wx changes from that date.
So we know that the problem is not present in wx CVS from 2006-03-07 and it is present in 2.6.3, which was released 2006-03-25. Is that time window already narrow enough or do you want me to compile aMule with a bunch of wx versions to narrow it down further?
-
Read your post, think which one gives me less work, answer yourself.
-
Well, it takes me about an hour to test one version of wx and it seemed like we already have a pretty good idea what code change to look for and a relatively narrow time window to look into, so I was just trying to make sure I don't invest hours into figuring out something that would only save you 3 minutes of looking through their commits.
That said, I'm more than happy to narrow down the time window further, it might take a day or two though.
-
But it would save ME one or two hours :P
-
And that's exactly why I asked. ;)
Now that we've established that it would actually save you a significant amount of time I can put the ice bags around my machine and start the compile-athlon. :)
-
Six builds later...
So I got it narrowed down to a 24h window: The long long bug is not present yet in wx CVS 2006-03-16 22:00 PST but it is present in wx CVS 2006-03-17 22:00 PST. I've tried to cut it down further but that proved tricky because compilation is broken for some parts of that interval.
Just, let me know if you need anything else. :)
-
First of all, lionel, you are a better man than I. Second, here's a phrase for you to learn: "Fuck off, Kry". :P
Now, your narrowing down the interval will no doubt help in finding the long long bug. Unfortunately, I've been (lazily) living with that bug in my aMule for quite some time. For me, it's only cosmetic. aMule runs fine but displays certain values incorrectly. So, the crashes you're experiencing may be due to some other unknown bug.
...
OK, so this is the change that caused the problem:
Index: include/wx/wxchar.h
===================================================================
RCS file: /pack/cvsroots/wxwidgets/wxWidgets/include/wx/wxchar.h,v
retrieving revision 1.190
retrieving revision 1.191
diff -u -r1.190 -r1.191
--- include/wx/wxchar.h 2006/03/09 13:16:02 1.190
+++ include/wx/wxchar.h 2006/03/17 14:26:59 1.191
@@ -4,7 +4,7 @@
* Author: Joel Farley, Ove KÂven
* Modified by: Vadim Zeitlin, Robert Roebling, Ron Lee
* Created: 1998/06/12
- * RCS-ID: $Id: wxchar.h,v 1.190 2006/03/09 13:16:02 VZ Exp $
+ * RCS-ID: $Id: wxchar.h,v 1.191 2006/03/17 14:26:59 SC Exp $
* Copyright: (c) 1998-2002 Joel Farley, Ove KÂven, Robert Roebling, Ron Lee
* Licence: wxWindows licence
*/
@@ -880,7 +880,8 @@
#if defined(HAVE__VSNWPRINTF)
#define wxVsnprintf_ _vsnwprintf
/* MinGW?MSVCRT has the wrong vswprintf */
- #elif defined(HAVE_VSWPRINTF) && !defined(__MINGW32__)
+ /* Mac OS X has a somehow buggy vswprintf */
+ #elif defined(HAVE_VSWPRINTF) && !defined(__MINGW32__) && !defined(__DARWIN__)
#define wxVsnprintf_ vswprintf
#endif
#else /* ASCII */
Unfortunately, that only means that wx switched from using the built-in vswprintf to using wx's own implementation of that function. And it doesn't explain why, really ("somehow buggy").
The real problem is that wx's implementation is itself buggy, so they switched from one perhaps-buggy implementation to a definitely buggy one. And the change doesn't help us figure out why the wx implementation is buggy.
-
Heh, thanks ken, I'll write that down for the next time I feel suicidal. ;)
Also thanks for locating the source of the problem.
Well, I'm not sure how to proceed, guys. In terms of the crashing bug, I can post the backtrace again on the testing forum if that is any help. If there is anything else I can do to facilitate fixing this issue, please let me know.
Concerning the long long bug, even if this is really only affecting the display of numbers but not stability, I don't think we can release aMule binaries where all the displayed times are butchered. So again, if there's anything I can do please let me know.
-
Well, I've never seen whatever bug the wx folks thinks exists in Mac OS X's vswprintf. So, I'm inclined to just revert their change. In other words, just remove the " && !defined(__DARWIN__)" from the end of that line in include/wx/wxchar.h.
As for the crash, I'll take another look, but I don't know if I'll have any new insight. As I (unhelpfully) said, It Works Here. *shrugs*
-
Yeah, I had already thought about simply reverting their change myself, but I was afraid that that would provide us with an even buggier wx install, because other parts of wx might now expect wx's own version of vswprintf being used. If you think the chance for this to cause problems is not too high, I might try reverting to OS X's version of vswprintf.
-
Alright, I tried switching back to OS X's built-in vswprintf version and things are looking pretty good so far. First, as was to be expected, the display of times is working properly again. Second, the tabs can be right-clicked again (we already knew this). Third, and most importantly, I have not been able to make aMule crash again, despite switching wildly between different download category tabs under heavy cpu load, which was pretty much a guaranteed way to take down aMule when it was built against wx's version of vswprintf.
I will have to do a little more testing, but if everything goes well, I will post a new CVS binary soon. :)
-
Switching to wx version was done with the CVS log message
"Log: fix for sf bug 1448153: Widgets sample hangs on Japanese radio label"
https://sourceforge.net/tracker/index.php?func=detail&aid=1448153&group_id=9863&atid=109863
That was done March 17th.
On 28th May the wxVsnprintf implementation got added positional parameter support, but the log message says it's disabled at that point. However, I fail to find any #if 0 or anything that would actually disable that stuff.
I wonder if a checkout between 18th March and 27th May works fine.
Keep in mind that I haven't read the whole thread, if some dates have already been mentioned.
-
Just to avoid confusion, even wx checkouts from right after the vswprintf switch exhibit the same problem, so the issue has probably been in their code for some time.
For now it seems that manually reverting the vswprintf version works just fine for our purposes, but I am wondering if it would be good to get this fixed in wx, so that we won't run into any problems over the long term.
I was thinking about filing a bug report with them, but the problem is "aMule's display of times is screwed up when using wx's version of vswprintf" might not be very insightful to them, and unfortunately my understanding of the problem does not go much beyond that. So if somebody who has a better idea of why this is going on could file the report, that would be highly appreciated. :)
-
Well, it happens with aMule's unit tests ("make check"), too. Basically, it's the "unsigned long long" format specifier "%ull" that doesn't work properly in wx's wxVsnprintf. I'm not certain if the "unsigned" is required; it might be that the "long long" format specifier "%ll" is also broken.
EDIT 1: I looked at the wxVsnprintf code a bit. It's complicated, so I'm not sure I followed it correctly, but I don't think it will work with long long format specifiers on any platform. The only reason long longs ever print properly is that the vast majority of platforms use the native library, not wx's implementation (as we've discovered on the Mac).
EDIT 2: Hmm. I just tried and aMule's unit tests don't compile these days. Anyway, the problem is as I've described it above.
-
Well, I guess if most other platforms use their own vswprintf implementation anyway, maybe we can just keep patching wx so that it uses the one built into OS X.