jiebi/CodeConvo huggingface dataset:
It have something to do with initializing the logs in , but I have no clue what specific small detail it is that breaks it <details<summaryExe code (not much interesting)</summary<p</p</details<details<summaryDLL code</summary rust-toolchain </p</details
Ok, I've submitted a fix. See the PR linked above. is tricky because of the loader lock and other tricks the OS does while a dll is loading.
I know is tricky, but is there any better option to do initialization, if I do not control the exe? And I need to fix the exe (by doing memory patches) before it reaches its .
Possibly not, which is why I filed a fix. Using the std in only works on a "best effort" basis. We do try to support it as much as reasonably possible but there are always going to be limitations due to the OS.
I get maybe a bit crazy idea, but my DLL hooks functions anyway, so if I would limit to and before the hooked main do my initialization. (for my use case any time before main is good enough) Would that eliminate wast majority of potential breaks related to ? Or is it not worth it?
Calling load_library in is susceptible to deadlocks unless the library is already loaded. I think you might just need to be very careful about the dependencies you use. Maybe there's a different or lighter weight logger you can use in place of log4js that doesn't use HashSet?
On further inspection it seems unlikely that fixes the issue although I still think it's a good cleanup and simplification (so I stand by my r+). That is, looking at your back trace... the deadlock you're hitting is from inside BCryptGenRandom itself, not from our code that synchronizes while calling it. It looks like BCryptGenRandom does some synchronizing when getting the preferred RNG (I guess). My hunch is for whatever reason this ends up needing to take the loader lock, and because the loader lock is already held inside , this causes a deadlock. If this is the case, I don't think there's a way for us to solve it... we can't detect it this in advance, nor is there a good alternative approach we can take that doesn't make things worse when outside (and/or on newer systems, which apparently works?). So I'm not sure what we can do about this.
To be clear, we (at least at the moment) don't really support calling into libstd from initialization contexts like DllMain. We sometimes fix bugs from this it, but mostly on a best-effort basis, which depending on stuff like severity/impact/maintance burden/hackiness/the weather/etc, all of which is mostly judged on an ad-hoc basis. Even when we fix it, there's no guarantee it'd going to keep working in the future. Given that it's only broken on Win7[^1] and there doesn't seem to be a great approach that wouldn't make things worse outside of it (and/or for on newer windows), I'm inclined to just say... sorry, it's not really supported. Anyway, while things from libstd like HashMap (well, the it uses in particular) is unlikely to be viable in DllMain (at least on win7), I think things from liballoc should be fine (so long as your allocator supports it), so my recommendation might be to switch to using /, which shouldn't have this issue. Another option would be to use a different hasher that doesn't need randomness, but be careful about that. [^1]: It may be worth reconsidering if this happens on newer Windows as well. There are some... unpleasant approaches we could consider, but I don't think they're worth it for Win7 given how close to EOL it is, and the fact that we don't really support use from DllMain anyway.
I am loading an dll from DLL main for years now, and you just told me that Microsoft can screw me over at any time Well thanks for warning. I will keep doing that and hope Microsoft will never change that.
If you scroll down this page it has a list of things Microsoft says you should never do in DllMain:
This is what I was saying before about the stack trace not actually reflecting the changes -- but I also mentioned the bizarre coincidence that this hang bisects to exactly the same nightly as the one with the patch. I agree with keeping the revised changes in all cases and libstd support being a best-effort deal, but I'm guessing that something in how/what gets locked/attempted before the call into changes the state in some unsupported way that caused the bug to surface. I'd be curious what Application Verifier finds if you run it against a minimum repro.
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Minimized from a program was trying to debug. I tried this code: I expected to see this happen: Instead, this happened: I see this on aarch64 and not on x86_64. I don't have access to any other architectures. Output is as expected with . I can also observe this bug on the previous stable (1.56.1), current beta (1.58.0-beta.3) and current nightly ( 2022-01-10). :
Was able to also test Rust 1.53 & 1.55, both perform as expected and show i: 0
Are the numbers printed the same every time or do they vary?
Consistently on the problem arch & compilers
Thanks. The reason I was asking is that, if you're reading invalid memory, the result is usually random. Since this result is consistent, something else is probably going on.
For the sake of convenience, could you please provide the output for this program?
here you go:
It might be a coincidence but, is (4 bytes in 32-bits) and rounded to the . Seems like maybe the bits are being inverted?
~I'm able to reproduce with , but if I emit the IR and then compile it with , I do not see the issue.~ I get different IR if I compile with vs. the entire command from . Only the 2nd has the bug. Edit: It's caused by . Lowering it to removes the problem.
When I use the llc from the rustup toolchain, I see LLVM going wild with clobbers: Note that also gets passed , so we're actually converting some condition flags to float, which makes about zero sense. Weirdly I don't see this when using the llc from my local rust build :/
For this example, the llc distributed by rustup produces (with ): While my own build produces:
Looks like it works if LLVM is compiled with assertions and breaks when compiled without assertions :(
Are you saying that you can reproduce two different results using the same IR? I was seeing the issue with distributed from Homebrew. Not sure if that's compiled with or without assertions.
I only see the problem with IR generated with and compiling with . This is the line of IR that is causing the issues. It is only present with and removing it fixes the bug: Additionally, it's only a problem if I assign to the spill directly. If I store a constant or use a temporary, the issue goes away.
seems like it may be relevant. Switching to fixes the miscompilation.
Bisect shows this is fixed by on main. Edit: It looks that shortly after that landed and the change was reverted again.
The revert comment suggests that it should be fixed by . Are you able to confirm?
I've filed to check whether we can still get this in 13.0.1, though probably not. In that case I'll cherry-pick into our fork.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Ah, I see now. That PR removes splats (hopefully temporarily), and unfortunately, because of how natural it is, a few tests for Miri already use the splatting syntax. Yes, I can clean this up.
Yeah I just tried and was happy to see it work. :)
Fix happening on the Miri side in (it was so easy I just quickly did it)
I was just investigating a that Fedora's rust binaries for armv7hl use NEON, but they should not per , supposedly fixed in . (Fedora's build is 1.11, but I applied that patch.) I can see the exact same issue in the latest official , whose version file says . In particular, they flagged that as a problem. I'm no ARM expert, but from it appears the registers are NEON-only. I believe those instructions using are also a problem, because with VFP3-D16 we should only have to .
Hm looks like it's definitely still there:
( TIL of ! :open_mouth: )
Just to confirm: No . This doesn't explicitly mention vs. though. I ran on all binaries in . I see no mention of NEON registers. I see uses of -, but no higher, so I think is OK too. I'll know better if someone with a limited armv7 actually tries to run this, but LGTM!
Thanks for the confirmation
This program takes an inordinate amount of time and memory to compile (it's worse if the array is actually used, but this is a minimal test case): const SIZE: usize = 1 << 30; static SLICE: [u8; SIZE] = [0u8; SIZE]; fn main() {} I was hoping this would be a viable way to get a big chunk of so I don't have to depend on an crate to get a lot of static zeroes, but the effect on compile time makes that impractical. If I run , the big offender is: Although the time (and memory) is reportedly spent checking lints, setting doesn't make any difference. I'm guessing the "lint checking" pass includes some things that need to be checked even if lints are suppressed? If not, it seems like a separate issue is that a lot of work could be saved with cap-lints set (e.g. when compiling dependencies). Here are the top results from , for : So it looks like miri is actually creating the array and folding over it. I know it's not going to find any problems, because I have ECC memory :laughing:. There are already some bugs relating to slow compilation of large arrays, with the most relevant I could find being , . I think this is separate from those cases because: the input in this case is a [0; _] array, whereas the others initialize arrays from sequences of elements those cases seem to refer to superlinear runtime; this issue appears roughly linear in time and space and only becomes noticeable for much larger arrays the bottleneck in this case occurs during lint checking, which I didn't see in any other array performance bugs
Have you seen any improvement after ?
I've wondered before whether we should special-case constants whose bits are all defined and zero. I'll open a discussion in the const-eval zulip channel.
I also ran into this problem. has that discussion happened?
Kind of. We will have special treatment for constants that consist solely of undef bytes (see ). This scheme can likely be extended to support all bytes being zero withour requiring time or space overhead.
I opened for this.
was closed, are there still plans to implement this?
Not right now... there are other more important construction sites in const eval.
url: function: asref() Examples: Perhaps I'm just confused, but shouldn't that say: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Transferring to the rust-lang/rust repository, as that is where the standard library documentation is. I think it is trying to illustrate the conversion from → → . The text is just eliding the middle step, and explaining where it is starting from and where it is finishing.
No, that seems fine; what confuses you (or leads you to the &str conclusion)? I could follow but not . Perhaps you're thinking the impl on would make the contain or such?
I guess I'm extremely confused then. If I have an , what good does an do me? If I have &Some( "fubar" ), how does that translate to a usize? Is it giving me the length of the string or it's pointer in memory? Neither seems useful nor relevant to the description of "Converts from &Option<Tto Option<&T.".
You can call . just describes the example code's functionality, not 's. It's showing one of the ways you could use .
Okay, sorry, I understand now that comment is talking about the upcoming example instead of discussing as_ref() in general. In order to help others not experience the same confusion I did, perhaps I could suggest a tweak to the wording, such as: ?
memory address
claim
I was under the impression that should work on stable channel with version 1.51, however using the example code from I get rustc -Vv output (its the ):
attributes are used to enable unstable/gated features in the nightly compiler. Once a feature stabilizes, the attribute is no longer required.
I think the compiler should suggest removing the feature gate if it's been stabilized.
I see, I was unsure whether the error message was referring to the referred feature or the feature flag itself (since the example code of the stabilize PR was using it too I was assuming the former). And yes, removing the feature line from the example code makes it compile, thanks. Is there any way to make rustc ignore the feature flag and try to compile it anyway? The crate I want to use still has it included and I'd prefer not having to remove it manually until it gets removed upstream. (re-opening since seems to think its a valid issue/suggestion)
No, you'll need to either patch the crate or fix it upstream.
searched nightlies: from nightly-2024-03-07 to nightly-2024-03-10 regressed nightly: nightly-2024-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: aarch64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-nightly -regression-untriaged
I suspect caused this regression, but I don't know how to use to test this pr(I tried some times but all failed). Do you have any ideas about this?
if you use the latest version of cargo-bisect-rustc it will bisect the roll-up for you.
Hi, I'm using the latest version of , but seems that it fails to bisect the roll-up. Here's the complete log: bash cargo bisect-rustc --start 2024-03-08 --end 2024-03-09 
It does bisect to for me. (With this visitor change in particular )
The fix has landed on master. Reopening to track beta backport.
Hi, 1.77.0 has been released, can this be backported to beta now?
I wasn’t at the weekly meeting and I don’t know for sure: is not yet marked as accepted for backport (it may just be an oversight in labeling, I’ll try to find out). Once that is done though, the release team, I believe, will backport it.
updated labels on (sorry for the delay)
That was backported in .
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and -- nominating for prioritization.
I suspect the or-pattern PR, , is to blame.
Fix for Clippy repo:
The unbounded channel implementation from can segfault due to what looks like a race condition when dropping channel senders and receivers. You can find a repro at Unfortunately it is not minimal at all, since it depends on the timely-dataflow crate, which is the actual channel user. I hope it is still self-contained enough that people familiar with the channel implementation can run it and use it as a starting point for debugging. Run the example like this: On some machines it will segfault after some time, e.g.: The segfault happens inside , as visible in the gdb backtrace below. The same segfault also happens with . You can reproduce this by reverting the second-to-last commit on the repro branch. I understand that is a port of , so that's not surprising. : I can reproduce the segfault on nightly as well. The segfault is not reproducible on all machines! We were able to reproduce it on: a c5.2xlarge EC2 instance running Ubuntu an AMD Threadripper Thinkpad running Debian an Intel i5-8250U Dell XPS 13 running Arch Linux It doesn't seem to reproduce on: an M1 MacBook Pro Also note that the repro is using more and more memory over time. That is because the different worker threads create and drop dataflows at different speeds and timely-dataflow keeps per-dataflow communication state (including channels) around until the last worker has dropped the dataflow. It is possible to avoid that by adding a that lets late workers catch up, but in my experience that also stops the segfault from happening. <details<summaryBacktrace</summary<p</p</details
Here are the results of some initial investigation I have been doing. I used , but I assume the results will apply to the std port as well: The segfault happens in . In the linked line, is a null pointer, and so is . It seems like there is an inconsistency between the channel's and . is pointing to nothing while points to a block. I observed the following variable assignments at the time of the segfault: If I change all the atomic orderings in to , the segfault still occurs. This suggests that the issue is not caused by the usage of too-weak orderings. If I add an after , it is triggered under the repro.
This is where the sender is advancing and it seems plausible that this is the place where the inconsistency between and described above is introduced. I couldn't figure out why becomes a null pointer. The same method makes sure that the head is allocated previously, so some other thread must set it to null after the check.
cc
This suggests that the issue is not caused by the usage of too-weak orderings. I wouldn't be so quick to write off an ordering issue, the race condition could require stronger synchronization to fix (e.g. fences).
The segfault did occur (after about 5 minutes of runtime) on my Macbook Pro with an Intel Core i7 processor running macOS 13.3 and rustc 1.68.2. So whatever is causing this, it's not exclusive to Linux.
I have a feeling the issue is to do with a CAS failure when updating the tail not synchronizing with the update to head. If the thread that actually makes the update is preempted, the second thread might continue with the assumption that head has been updated, which might matter if it quickly writes to the entire block and the channel is disconnected before the head is ever touched. I haven't verified if this is possible, but it would be extremely rare if it is, which explains why this issue hasn't been hit before.