Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Windows installer splats system PATH #1602

Closed
ssylvan opened this issue Jan 21, 2012 · 15 comments
Closed

Windows installer splats system PATH #1602

ssylvan opened this issue Jan 21, 2012 · 15 comments
Labels
O-windows Operating system: Windows
Milestone
0.2 release, deta...

Comments

@ssylvan
Copy link

ssylvan commented Jan 21, 2012

I've repro'd this twice. The windows installer will simply nuke the system PATH and put "C:\Program Files(x86)\rust\bin" in its place.

This is on Windows 7.
@brson
Copy link
Contributor

brson commented Jan 22, 2012

Good god.

@brson
Copy link
Contributor

brson commented Jan 22, 2012

Also #1591

@ghost ghost assigned brson Jan 22, 2012
@brson
Copy link
Contributor

brson commented Jan 22, 2012

I've removed the installer from the servers, will send an update to the mailing list. I hope this hasn't done any irrecoverable damage to your machine ssylvan.

@ssylvan
Copy link
Author

ssylvan commented Jan 22, 2012

No worries, System Restore FTW! :-)

@graydon
Copy link
Contributor

graydon commented Jan 25, 2012

Can you possibly try to catch me on IRC someday so we can try to diagnose this? That's a serious failure. I have a win7 machine here I want to try to reproduce it on.

(Alternatively, perhaps a paste of the PATH you had before the corruption?)

@graydon
Copy link
Contributor

graydon commented Jan 25, 2012

http://venge.net/graydon/rust-0.2-install.exe might also be worth taking a look at, if you trust Random Binaries From Me. That's an Inno Setup installer for a version with seemingly better-behaved path manipulation code, as well as fixed quoting in the compiler driver. Ought to be closer to working.

(Less than zero warranty on that; I just built it today on a somewhat random workstation)

@ssylvan
Copy link
Author

ssylvan commented Jan 25, 2012

So for the original installer, both the installer and the uninstaller
seems to think that the path is empty (and gives a warning to that
effect). That probably explains why it just splats it with the rust
path and nothing else (it mistakenly thinks the path is empty). The
only thing I can think of off the top of my head is that it's reading
the user's path but writing the system's path (the second half of that
statement is definitely true at least!), since my user path is empty.

The second installer seems to append the path to the user's PATH
variable. This works, however windows installers normally give you the
option of installing just for yourself, or for everyone (the latter
option would put it on the system's path).

The version of rustc.exe installed with that second installer hangs
after compiling. If I kill it, the executable produced seems to work
though. Perhaps I'll dig through it later and find you a call stack.

Seb

On Tue, Jan 24, 2012 at 7:30 PM, Graydon Hoare
reply@reply.github.com
wrote:

http://venge.net/graydon/rust-0.2-install.exe might also  be worth taking a look at, if you trust Random Binaries From Me. That's an Inno Setup installer for a version with seemingly better-behaved path manipulation code, as well as fixed quoting in the compiler driver. Ought to be closer to working.

(Less than zero warranty on that; I just built it today on a somewhat random workstation)

Reply to this email directly or view it on GitHub:
#1602 (comment)

Sebastian Sylvan

@ssylvan
Copy link
Author

ssylvan commented Jan 25, 2012

So I dumped the stack trace, unfortunately I don't have symbols for
the rustc stuff. Depending on when I take the stack trace I get some
variation of these two:

rustrt.dll!rust_process_wait+0x222b
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x4a8
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x429
ntdll.dll!RtlIsDosDeviceName_U+0x24c87
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0x15
kernel32.dll!WaitForSingleObjectEx+0x43
kernel32.dll!WaitForSingleObject+0x12
rustrt.dll+0x16d2
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36

It just sits there eating 12% CPU.

On Tue, Jan 24, 2012 at 7:55 PM, Sebastian Sylvan
sebastian.sylvan@gmail.com wrote:

So for the original installer, both the installer and the uninstaller
seems to think that the path is empty (and gives a warning to that
effect). That probably explains why it just splats it with the rust
path and nothing else (it mistakenly thinks the path is empty). The
only thing I can think of off the top of my head is that it's reading
the user's path but writing the system's path (the second half of that
statement is definitely true at least!), since my user path is empty.

The second installer seems to append the path to the user's PATH
variable. This works, however windows installers normally give you the
option of installing just for yourself, or for everyone (the latter
option would put it on the system's path).

The version of rustc.exe installed with that second installer hangs
after compiling. If I kill it, the executable produced seems to work
though. Perhaps I'll dig through it later and find you a call stack.

Seb

On Tue, Jan 24, 2012 at 7:30 PM, Graydon Hoare
reply@reply.github.com
wrote:

http://venge.net/graydon/rust-0.2-install.exe might also  be worth taking a look at, if you trust Random Binaries From Me. That's an Inno Setup installer for a version with seemingly better-behaved path manipulation code, as well as fixed quoting in the compiler driver. Ought to be closer to working.

(Less than zero warranty on that; I just built it today on a somewhat random workstation)

Reply to this email directly or view it on GitHub:
#1602 (comment)

Sebastian Sylvan

Sebastian Sylvan

@brson
Copy link
Contributor

brson commented Jan 25, 2012

I have heard other reports of rustc.exe successfully producing output but hanging. That wait loop in rust_process_wait could possibly account for the livelocks we see on the windows bots sometimes.

@graydon
Copy link
Contributor

graydon commented Jan 27, 2012

ssylvan: I think inno permits me to separately flag add-to-user vs. add-to-system path variants. I will experiment with this if I have time (opening a sub-bug) but in the meantime, does it ever run, or always hang? I tried it on another mahcine yesterday and it just ran really slowly during startup. But it doesn't do that on the win7 dev desktop I have here or the win2008 server builder. So I'm curious if you can let it run for a bit, or help diagnose this hang.

Thanks for all the help!

@ssylvan
Copy link
Author

ssylvan commented Jan 27, 2012

It spit out the executable and I left it running for several minutes
after that, periodically probing the call stack. I don't really have a
windows/rust dev environment set up so I can't really do too much (I
believe I tried setting it up once, but failed to figure out some
linux-y dependency, I forget what). I can try just leaving it running
for an hour or so to rule out that it's just slow.

Seb

On Thu, Jan 26, 2012 at 5:31 PM, Graydon Hoare
reply@reply.github.com
wrote:

ssylvan: I think inno permits me to separately flag add-to-user vs. add-to-system path variants. I will experiment with this if I have time (opening a sub-bug) but in the meantime, does it ever run, or always hang? I tried it on another mahcine yesterday and it just ran really slowly during startup. But it doesn't do that on the win7 dev desktop I have here or the win2008 server builder. So I'm curious if you can let it run for a bit, or help diagnose this hang.

Thanks for all the help!

Reply to this email directly or view it on GitHub:
#1602 (comment)

Sebastian Sylvan

@ssylvan
Copy link
Author

ssylvan commented Jan 27, 2012

FYI I let it run for several hours yesterday and it never finished, so
looks like there's a genuine hang there.

Seb

On Thu, Jan 26, 2012 at 6:17 PM, Sebastian Sylvan
sebastian.sylvan@gmail.com wrote:

It spit out the executable and I left it running for several minutes
after that, periodically probing the call stack. I don't really have a
windows/rust dev environment set up so I can't really do too much (I
believe I tried setting it up once, but failed to figure out some
linux-y dependency, I forget what). I can try just leaving it running
for an hour or so to rule out that it's just slow.

Seb

On Thu, Jan 26, 2012 at 5:31 PM, Graydon Hoare
reply@reply.github.com
wrote:

ssylvan: I think inno permits me to separately flag add-to-user vs. add-to-system path variants. I will experiment with this if I have time (opening a sub-bug) but in the meantime, does it ever run, or always hang? I tried it on another mahcine yesterday and it just ran really slowly during startup. But it doesn't do that on the win7 dev desktop I have here or the win2008 server builder. So I'm curious if you can let it run for a bit, or help diagnose this hang.

Thanks for all the help!

Reply to this email directly or view it on GitHub:
#1602 (comment)

Sebastian Sylvan

Sebastian Sylvan

@graydon
Copy link
Contributor

graydon commented Jan 27, 2012

Here's the state of one of our hung build machines:

info threads
  6 Thread 2012.0x334  0x76f7000d in ntdll!LdrFindResource_U () from ...\ntdll.dll
  5 Thread 2012.0x5dc  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
  4 Thread 2012.0xb68  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
  3 Thread 2012.0x520  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
  2 Thread 2012.0x354  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
  1 Thread 2012.0xb78  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll

thread 6:

#0  0x76f7000d in ntdll!LdrFindResource_U () from ...\ntdll.dll
#1  0x76fff896 in ntdll!RtlQueryTimeZoneInformation () from ...\ntdll.dll
#2  0x741b1d99 in ?? ()
#3  0x00000000 in ?? ()

thread 5:

#0  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
#1  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
#2  0x74bb0a91 in WaitForSingleObjectEx () from ...\KernelBase.dll
#3  0x00000110 in ?? () at ...stl/stl_tree.h:1244
#4  0x74e91194 in KERNEL32!GetPrivateProfileStructA () from ...\kernel32.dll
#5  0x00000110 in ?? () at ...stl/stl_tree.h:1244
#6  0x74e91148 in KERNEL32!GetPrivateProfileStructA () from ...\kernel32.dll
#7  0x00000110 in ?? () at ...stl/stl_tree.h:1244
#8  0x61901730 in lock_and_signal::timed_wait (this=0x1b6e0f4, timeout_in_ms=10) at .../sync/lock_and_signal.cpp:77
#9  0x619058fb in rust_scheduler::start_main_loop (this=0x1b6d838) at .../rust_scheduler.cpp:269
#10 0x619014e0 in rust_thread_start (ptr=0x1b6d838) at .../sync/sync.cpp:34
#11 0x74e9339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from ...\kernel32.dll
#12 0x01b6d838 in ?? ()
#13 0x76f99ef2 in ntdll!RtlpNtSetValueKey () from ...\ntdll.dll
#14 0x01b6d838 in ?? ()
#15 0x76f99ec5 in ntdll!RtlpNtSetValueKey () from ...\ntdll.dll
#16 0x619014d0 in timer::timer() () from ...\rustrt.dll

thread 4:

#0  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
#1  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
#2  0x74bb0a91 in WaitForSingleObjectEx () from ...\KernelBase.dll
#3  0x00000108 in ?? () at ...stl/stl_tree.h:1244
#4  0x74e91194 in KERNEL32!GetPrivateProfileStructA () from ...\kernel32.dll
#5  0x00000108 in ?? () at ...stl/stl_tree.h:1244
#6  0x74e91148 in KERNEL32!GetPrivateProfileStructA () from ...\kernel32.dll
#7  0x00000108 in ?? () at ...stl/stl_tree.h:1244
#8  0x61901730 in lock_and_signal::timed_wait (this=0x13d61c4, timeout_in_ms=10) at .../sync/lock_and_signal.cpp:77
#9  0x619058fb in rust_scheduler::start_main_loop (this=0x13d5908) at .../rust_scheduler.cpp:269
#10 0x619014e0 in rust_thread_start (ptr=0x13d5908) at .../sync/sync.cpp:34
#11 0x74e9339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from ...\kernel32.dll
#12 0x013d5908 in ?? ()
#13 0x76f99ef2 in ntdll!RtlpNtSetValueKey () from ...\ntdll.dll
#14 0x013d5908 in ?? ()
#15 0x76f99ec5 in ntdll!RtlpNtSetValueKey () from ...\ntdll.dll
#16 0x619014d0 in timer::timer() () from ...\rustrt.dll
#17 0x00000000 in ?? ()

thread 3:

#0  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
#1  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
#2  0x74bb0a91 in WaitForSingleObjectEx () from ...\KernelBase.dll
#3  0x00000100 in ?? () at ...stl/stl_tree.h:1244
#4  0x74e91194 in KERNEL32!GetPrivateProfileStructA () from ...\kernel32.dll
#5  0x00000100 in ?? () at ...stl/stl_tree.h:1244
#6  0x74e91148 in KERNEL32!GetPrivateProfileStructA () from ...\kernel32.dll
#7  0x00000100 in ?? () at ...stl/stl_tree.h:1244
#8  0x61901730 in lock_and_signal::timed_wait (this=0x13d587c, timeout_in_ms=10) at .../sync/lock_and_signal.cpp:77
#9  0x619058fb in rust_scheduler::start_main_loop (this=0x13d4fc0) at .../rust_scheduler.cpp:269
#10 0x619014e0 in rust_thread_start (ptr=0x13d4fc0) at .../sync/sync.cpp:34
#11 0x74e9339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from ...\kernel32.dll
#12 0x013d4fc0 in ?? ()
#13 0x76f99ef2 in ntdll!RtlpNtSetValueKey () from ...\ntdll.dll
#14 0x013d4fc0 in ?? ()
#15 0x76f99ec5 in ntdll!RtlpNtSetValueKey () from ...\ntdll.dll
#16 0x619014d0 in timer::timer() () from ...\rustrt.dll
#17 0x00000000 in ?? ()


thread 2:

#0  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
#1  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
#2  0x74bb0a91 in WaitForSingleObjectEx () from ...\KernelBase.dll
#3  0x000000e8 in ?? () at ...stl/stl_tree.h:1274
#4  0x74e91194 in KERNEL32!GetPrivateProfileStructA () from ...\kernel32.dll
#5  0x000000e8 in ?? () at ...stl/stl_tree.h:1274
#6  0x74e91148 in KERNEL32!GetPrivateProfileStructA () from ...\kernel32.dll
#7  0x000000e8 in ?? () at ...stl/stl_tree.h:1274
#8  0x61901730 in lock_and_signal::timed_wait (this=0x13d4e14, timeout_in_ms=10) at .../sync/lock_and_signal.cpp:77
#9  0x619058fb in rust_scheduler::start_main_loop (this=0x13d4558) at .../rust_scheduler.cpp:269
#10 0x619014e0 in rust_thread_start (ptr=0x13d4558) at .../sync/sync.cpp:34
#11 0x74e9339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from ...\kernel32.dll
#12 0x013d4558 in ?? ()
#13 0x76f99ef2 in ntdll!RtlpNtSetValueKey () from ...\ntdll.dll
#14 0x013d4558 in ?? ()
#15 0x76f99ec5 in ntdll!RtlpNtSetValueKey () from ...\ntdll.dll
#16 0x619014d0 in timer::timer() () from ...\rustrt.dll
#17 0x00000000 in ?? ()


thread 1:

#0  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
#1  0x76f7f8b1 in ntdll!RtlUpdateClonedSRWLock () from ...\ntdll.dll
#2  0x74bb0a91 in WaitForSingleObjectEx () from ...\KernelBase.dll
#3  0x0000011c in ?? () at ...stl/stl_tree.h:1263
#4  0x74e91194 in KERNEL32!GetPrivateProfileStructA () from ...\kernel32.dll
#5  0x0000011c in ?? () at ...stl/stl_tree.h:1263
#6  0x74e91148 in KERNEL32!GetPrivateProfileStructA () from ...\kernel32.dll
#7  0x0000011c in ?? () at ...stl/stl_tree.h:1263
#8  0x619015c1 in rust_thread::join (this=0x13d4558) at .../sync/sync.cpp:56
#9  0x6190c104 in rust_kernel::start_task_threads (this=0x13d3c90) at .../rust_kernel.cpp:132
#10 0x61901c3b in rust_start (main_fn=4207600, argc=4194304, argv=0x0, crate_map=0x406000) at .../rust.cpp:106
#11 0x00403461 in WinMain@16 ()
#12 0x004033f0 in main::_6178e9efa23b8931 ()
#13 0x00400000 in ?? ()
#14 0x00405896 in main ()

@kyonifer
Copy link

I have the same issue with rustc immediately producing the output binary but hanging indefinitely afterwards. It occurs with both the installer posted above by graydon and when I build from source via mingw/msys (and then move stuff around so everything needed is in the path).

@ghost ghost assigned graydon Jan 30, 2012
@graydon
Copy link
Contributor

graydon commented Jan 31, 2012

Will open a separate bug on hanging. This one (munged path) is closed by 0bf9929

@graydon graydon closed this as completed Jan 31, 2012
@graydon graydon mentioned this issue Jan 31, 2012
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
O-windows Operating system: Windows
Projects
None yet
Milestone
0.2 release, detail work, cleanup and...
Development

No branches or pull requests
4 participants
@graydon @brson @kyonifer @ssylvan