 |
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Chris Green - [10/14/07 06:55 PM ]
I'm having this same issue on Windows Vista in 3.0 Beta 2.
Me as well running vista with Flex 3 beta.
Is there a work around ? I just upgraded to Windows Vista x64. Using Flex Builder 3 beta 2. I'm having this issue also, and as stated I can't recover from it until I reboot.
I figured out a workaround on Vista without a reboot, but it's kind of a pain since it has to be done after a great majority of the debug session I run.
Basically when app is run in debug mode, a process called IEUser.exe is kicked off. In the case of the "another debugger is running" error, if I kill that IEUser.exe process then all is well again without reboot. Here's what that process looks like in WIndows Defender: File Name: IEUser.exe Display Name: Microsoft Internet Explorer Description: Internet Explorer Publisher: Microsoft Corporation Digitally Signed By: Microsoft Windows Verification PCA File Type: Application Auto Start: No File Path: C:\Program Files (x86)\Internet Explorer\IEUser.exe File Size: 294912 File Version: 6.0.6000.16386 (vista_rtm.061101-2205) Date Installed: 10/10/2007 12:38:39 PM Process ID: 4308 User Name: FROST\jun Classification: Permitted Ships with Operating System: Yes Maybe that helps enough so we can get this fixed? :) This has six votes, and variations on this have also been seen internally. Sending to internal review.
I just now finally figured out a workaround for the occasional problem when using Flex Builder on Vista, where Flex Builder tells you that another debugger is already running.
The workaround is to add this line to flexbuilder.ini or eclipse.ini (the name of the ini file depends on whether you installed standalone Flex Builder or the Eclipse plugin version of Flex Builder): -Djava.net.preferIPv4Stack=true That's it. I suspect a bug in Vista -- the first time you debug, I can clearly see that Flex Builder is closing the socket, but when I run TCPView, it shows that the IPv6 version of the socket is still open, and that causes the problem. Adding the above property definition causes Java to only use IPv4. Now that we know a workaround, this should be assigned to Chris to fix in the installer. It comes down to having the installer add "-Djava.net.preferIPv4Stack=true" to the flexbuilder.ini or eclipse.ini file. (This needs to be anywhere AFTER the "-vmargs" line.)
For Flex Builder standalone, it's a no-brainer to add this to flexbuilder.ini. For Flex Builder plugin, it's trickier: we need to read the user's eclipse.ini file, add this line to the end, and write it back out. Opened to ChrisAg
as mentioned, there are two work items here. Altering the flexbuilder.ini should be easy. i'm not sure about the addition of the arg to the eclipse.ini. Let us know if you would like a separate bug for that item I've made the modifications for the standalone ini files (flexbuilder.ini) already now, and am adding the changes for Plugin to the installers.
Important: with plugin installations we won't always be able to find the path to eclipse.ini, particularly if we're installing into a heavily customized or 3rd party product environment. Most of the time we will be able to find it though, and I can add the new line easily in those cases. I thought this was quite interesting. It turns out the IPv6 problem I was running into is not a Window bug, a player bug, or a Flex Builder bug. (There may be a JVM bug.)
Microsoft was able to reproduce the problem, and they were asking me if I could give them a snippet of code that reproduced the problem. In the process of trying to do that, I made an important realization (and this is probably the key to why my ability to reproduce the problem was inconsistent): It all depends on whether Flex Builder launched the browser (with CreateProcess) or if the browser got launched in some other way. Socket handles are inherited by child processes! I had forgotten about that. This is by design (see http://support.microsoft.com/kb/150523 ). If you want to make a socket that will not be inherited, then after creating a socket, you can call DuplicateHandle to create a duplicate socket which is not inheritable, and then close the orginal socket. (The above URL gives sample code to do the opposite -- create a handle and then make a duplicate which is inheritable -- because Win95 and Win98 sockets were non-inheritable by default.) By writing a small C program, I was able to verify that the problem occurs even with ip4, and even if no one connects to the other end of the socket (in other words, the Flash player has nothing to do with this). My C program did this: - create a traditional IPv4 socket, by calling socket(), bind(), and listen() - spawn a child Notepad.exe process via CreateProcess - close the socket - block, waiting for a keystroke At that point, I ran TCPView, and confirmed that the socket was still open, and still in the "listening" state. This is because Notepad.exe has inherited the handle, so it is still open. I also tried variations on the above -- e.g. after creating the socket but before spawning Notepad, I did the DuplicateHandle trick. When I did that, as expected, Notepad did not inherit the handle, so TCPView showed it as being closed. This explains a whole lot -- it explains some of the really weird, difficult-to-reproduce behavior I saw. For example, when debugging with IE, why in the world did IE Protected Mode make any difference at all? Well, because when FlexBuilder.exe launches IExplore.exe in protected mode, IExplore.exe turns around and launches IEUser.exe. So now IEUser.exe has the socket open. Even after IExplore.exe terminates, and FlexBuilder.exe terminates, IEUser.exe is still open, so the socket is open. This also explains why I couldn't always reproduce the bug. If IEUser.exe was already running before I began my tests (because e.g. another instance of IE had opened it), then IEUser.exe would not have that handle, so everything would be okay. So the next question is, in Flex Builder, why did we see problems with the IPv6 socket but not the IPv4 one? My guess is that the native code inside the JVM does DuplicateHandle to prevent the IPv4 socket from being inherited, but does not do the same thing with the IPv6 socket. I will probably log a bug with Sun. The workaround we came up with for now (which we will ship with) is that Flex Builder disables IPv6. In terms of coming up with a better workaround, what would work if it were at all possible would be to call DuplicateHandle on the socket that came back from Java. That might be possible with some hacky code, but it is quite hard -- it involves doing a native JNI call, and Flex currently has no JNI code. (Flex Builder does have JNI code, but this stuff is part of Flex's fdb debugger, which does not.) Another workaround would be to first launch the browser, and then open the socket. But that is a little dangerous, because it causes a race condition: In the unlikely event that the browser starts the player before Flex Builder has had a chance to open the server socket, debugging would fail. But anyway, no problem, the workaround we have is sufficient for the time being. I am running Flex Builder V3.0 build 3.0.194161 on eclipse Version: 3.3.1.1Build id: M20071023-1652 on windows Vista with IE Version 7 and i am recieving the same error. Only way i can resolve this is by killing ieuser.exe through task manager. My eclipse.ini contents is
-showsplash org.eclipse.platform --launcher.XXMaxPermSize 256M -vmargs -Dosgi.requiredJavaVersion=1.5 -Xms40m -Xmx256m -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Stack=true Any permanent fixes for the issue? Setting Flex Builder to Run as Administator worked for me (as opposed to disabling UAC). This still occurs on Vista SP1 even in Flex Builder 3 and even with IPv6 completely disabled, but Run as Admin fixes it.
Reproduced on Vista, SA, 1.6, build 204623.
This workaround worked for me: 1) Kill ieuser.exe in task manager 2) Start FB with Run as Administrator Easier steps to repro in Vista:
- Debug any app (no breakpoints or other activity necessary) - Close IE - Debug again - Observe error dialog Workaround - Kill ieuser.exe - Debug again - Observe IE is open and debug continues as normal Note: Run as Administrator is not necessary. Reproduced again today on Vista, SA, 1.6, build 205599. But this time instead of closing IE to end the debug session, I used the Stop button in the Debug view toolbar.
Almost the same problem (with one exception) on Microsoft Windows Professional Service Pack 3,
in Flex Properties: "General --> Web Browser --> Use internal web browser --> FireFox". Flex Builder 3 Standalone version: 3.0.194161. The problem occurs after just once launched the application by "F11", not 5-6 times. The exception is workaround: for my case workaround is not rebooting the system but closing and then reopening the Flex Builder:-? Just looked into FlexBuilder.ini file. The following string
-Djava.net.preferIPv4Stack=true is there, so.. my only workaround is to restart Builder any time i want to debug:((((( Found another workaround (Windows XP SP3, FireFox):
1.) open Flex Builder -1.1) close FireFox if it is not closed 2.) launch the project once by "F11" -flex running my project in FireFox and connecting to the debugger 3.) just after the project is launched in FireFox: close FireFox 4.) press in Flex Builder "F11" again after that combination all works as expected Assigning to Chris, because the current Flex Builder 4 issue is just an installer issue: the .ini file does not include the -Djava.net.preferIPv4Stack=true option. (In fact, the .ini file appears to be incorrectly formatted: all the carriage returns have been removed, so the entire file appears as one long line.)
This bug was resolved a long time ago, but just for posterity's sake, I wanted to record the link to the Java bug that caused this problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6598160
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
[smokes] Cannot Debug Launch Failed: "Another Flash debugger may be running. Close it to continue"
