498483 - Software update doesn't work when debugger is attached

Status: VERIFIED WONTFIX

(Toolkit :: Application Update, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)

When a debugger is attached to a Firefox build and you wanna update the application the updater will stop because of some files are in usage. No idea how often this will happen in the real world but I just wanna see a bug on it so we could fix it if wanted.

Steps:
1. Attach debugger e.g. windbg) to the application
2. Run software update and restart Firefox

After step 2 the updater will fail because some files are still in usage.

Comment 1

[Robert Strong (they/them - no direct email)]

The debugger has to disconnect and I don't think there is a anything at all that can be done about this. This is likely wontfix as well as impossible.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Isn't it similar to the situation we have with the crash reporter but with the difference that we block nearly all files with a debugger? Do we only check a couple of those files if they are locked?

Comment 3

[timeless]

robert: you can generally rename locked files.

1. ren foo.dll foo.dll.inuse
2. copy foo.dll.inuse foo.dll
3. patch foo.dll
4. profit

Comment 4

[Robert Strong (they/them - no direct email)]

If you restart the application (for software update or otherwise) the application will quit and after update start again with a new pid which the debugger won't know and hence won't reconnect. This is also an extreme edgecase and I highly doubt anyone that has connected to Firefox with a debugger wouldn't realize that the debugger is the cause of the failure.

With crashreporter it might be possible to copy the crashreporter binary to a temp location to avoid the in use bug during software update and I'm pretty sure that crashreporter doesn't offer to restart the app until after it has gathered its info from the app and allowed that instance to exit completely.

Comment 5

[Robert Strong (they/them - no direct email)]

(In reply to comment #3)
> robert: you can generally rename locked files.
> 
> 1. ren foo.dll foo.dll.inuse
> 2. copy foo.dll.inuse foo.dll
> 3. patch foo.dll
> 4. profit
timeless: spent time thinking on that quite some time ago.

This would affect other users on the system that are running Firefox or for that matter even a user where Firefox didn't exit cleanly during app update and put them in a state where the old dll's are still loaded while some of the files that have been patched could be loaded. It would be similar to franfenfox.

Comment 6

[timeless]

instead of simply copying back, copy back w/ an exclusive lock, that'd prevent anyone else from loading the libraries. i don't think there's much risk of encountering concurrent users.

i'm merely commenting because you said you didn't think there was *anything* that could be done, which is incorrect. i'm not saying you have to do it.

Comment 7

[Robert Strong (they/them - no direct email)]

We have had other bugs where it has been seen that concurrent users do happen much more often than I ever expected. A similar thing happened with the installer for 2.0 for example.

My reference was in regards that on app restart the debugger would have to disconnect since the app won't start back up before completing shutdown and hence the debugger would need to detach.

As for what app update the best we can do is bug 466778 (similar solution as comment #3 except the main binary might be renamed to prevent launching until after a restart so the dlls will be unloaded) so duping.

Comment 8

[Robert Strong (they/them - no direct email)]

Found it.

It is a requirement that the firefox.exe process is not loaded per the second half of bug 466778 comment #44. Also, supporting updates while a debugger is attached is to say the least a use case I and I highly suspect any other person would think is a valuable use of time trying to support.

Comment 9

[Robert Strong (they/them - no direct email)]

Went through the bugs that were duped and they *should* all be addressed except for bug 498483 which is the bug you filed to support updating while a debugger is attached which I just wontfix'd for the reason stated in bug 498483 comment #8.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Makes sense. Thanks Robert!