Hopac.Job.toAsync nullrefexn when try-with is used #153
Comments
|
Can you provide a complete example to reproduce this? |
|
I can give you access to a private repository that can reproduce it repeatedly...? I'll try to create a sample too. |
|
This is the function that initially passes along the null exception (I did null checks throughout Hopac to find it) With crash: |
|
Hmm... I wonder if this is CLR bug? See http://stackoverflow.com/questions/5634417/caught-exception-is-null-itself |
|
It's this line that's failing
Adding an |
|
Could it be this code?
...interacting with the goto-statements? It's implementation namespace Hopac.Core {
using Hopac.Core;
using System.Runtime.CompilerServices;
internal unsafe static class Unsafe {
[MethodImpl(AggressiveInlining.Flag)]
internal static byte *GetStackPtr() {
byte dummy;
return &dummy;
}
}
} |
|
Having a failure depend on whether or not there is an |
|
It's a stackoverflow in unmanaged code: |
|
I think it is an interaction between Work implementations between |
|
I'm going to check to see if this is a platform-related issue. Building the tests, and then will run them on .NET Framework. |
|
Getting all successful through Expecto, both DEBUG and RELEASE builds, when run on .NET Framework.
|
|
There is a platform-specific difference in how the static @haf, can you try adjusting the |
|
@neoeinstein Sure I can, but just to clarify; I haven't been able to create a simple repro yet, but I thought some generative tests could be useful to PR anyway. ;) Tomorrow I will scale down the complex (very complex) repro I have and try your suggestion. |
|
Yes, the idea is that Note that the Note that neither of these changes should really have any effect on what exception, apparently |
|
@polytypic I'm only running on mono and then it's my understanding that it doesn't use tail calls. @neoeinstein I've tried adjusting the stack size, doesn't have an effect. If I monkey around with the code, removing JobBuilder.Zero() calls and one The quest to add logging to Hopac continues. |
|
It's failing when it's trying to run this function, downcast to a Job<_> in turn run through /// A function that takes a retry timeout (defaults to 50ms) and a time budget
/// that it's allowed to spend, waiting for the passed alternative to
/// become available. Returns an alternative, which, if cancelled, also cancels
/// the passed alternative and the recursive checking after each retry timeout.
let private eventually retryTimeout budget =
fun (fn: Alt<'res>) cancelValue ->
let rec inner budget' nack =
// out of budget; return the cancel value
if budget' < TimeSpan.Zero then Alt.always cancelValue else
// otherwise, choose between the caller NACKing, retrying after the
// timeout and the user-supplied function
Alt.choose [
nack ^->. cancelValue
timeOut retryTimeout ^=>. inner (budget - retryTimeout) nack
fn
]
Alt.withNackFun (inner budget)
/// A constructed 'eventually' function with the defaults.
let private eval fn cancelValue =
eventually defaultRetry defaultBudget fn cancelValueSo in the end it's my own fault :) Awesome! The |
With code like this
eis null. The stack-trace above is if you comment out the try with. The code has the structure of;Alternatively:
If I use
|> runinside the async, this is the stack trace:The text was updated successfully, but these errors were encountered: