Named parameters throw AccessViolationException when debugging #178
Comments
|
Do you mean that the exception happens only during debugging but not when running without a debugger? I made a small change regarding named parameters in the 0.10.1.1 version, can you test with that one? |
|
We are encountering something similar running on osx and linux both with 0.10.1.1 (it's fine with 0.10.1) Which might have to do with the change you just mentioned, just executing the simplest of SQL: |
|
@JMcDanielFbn Looks like I messed up dependency numbers when publishing the NuGet packages. I re-uploaded |
|
@Giorgi yes I meant that the exception was only being thrown when using the debugger. However, I've just tested with 0.10.1.2 and seems like everything is fine now! Thank you for sorting this out 😄 |
|
Apologies @Giorgi, but I messed up my test. Looks like this is actually still happening 😞 Could you re-open this? |
|
I don't use either Ubuntu or Rider so there isn't much I can do to investigate this issue. I also find it strange that it happens only when debugging. The only thing I can suggest is that you try to reproduce it in a test C application using the DuckDB C API and see if it happens there or not. |
|
You could also try reproducing it on Windows. |
|
Tried running it in WSL but couldn't reproduce. |
|
Thanks for If it helps I use OSX & Rider - and do not get that issue when debugging. Any chance you have done a binary build of DuckDB @ntsim ? I found that when I did it took precedence over the packed-here binaries, which cost me a couple more hours than I would be proud to admit. In the end I did a |
|
@ntsim Did you have a chance to try the suggestions from the comments? |
|
@JMcDanielFbn @Giorgi Apologies for the delay getting back to you on this! I had the I've done some further debugging and depending on how I arrange breakpoints and debug, I can get the following exception to throw on In other cases, it's also possible to set the breakpoints so that it just crashes out around foreach (DuckDBParameter param in parameterCollection)
{
var state = NativeMethods.PreparedStatements.DuckDBBindParameterIndex(preparedStatement, out var index, param.Paramete
if (state.IsSuccess())
{
BindParameter(preparedStatement, index, param);
}
}Once I'm not super sure what's going on, but feels like the issue is within this general region? FWIW, I have managed to get around this issue by using question mark parameters ( public class MyDuckDbConnection(string connectionString): DuckDBConnection(connectionString)
{
public override MyDuckDbCommand CreateCommand()
{
// Bit rubbish to do this but we don't have access to the
// underlying `Transaction` so we need to get a reference
// to it through by creating a base command object first.
var wrappedCommand = base.CreateCommand();
return new MyDuckDbCommand
{
Connection = this,
Transaction = wrappedCommand.Transaction
};
}
}
public class MyDuckDbCommand : DuckDbCommand
{
protected override DbParameter CreateDbParameter() => new MyDuckDbParameter();
}
public class MyDuckDbParameter : DuckDBParameter
{
public override string ParameterName
{
// This is the hack that allows things to work by
// preventing `ParameterName` being set...
get => string.Empty;
set => base.ParameterName = string.Empty;
}
}Not sure if this the best way of going about things, but it was the only way to get things working. Ideally, the named parameters would work correctly as they've obviously got advantages over question mark parameters. |
|
Do you get these exceptions only if debugging? Named parameters do work on all platforms when the tests run on GitHub Actions. If you can share a reproducible code I'll try to see what's going on but I also suspect it has something to do with your environment. |
|
Yes, these exceptions only occur whilst debugging with named parameters. They don't occur when debugging with the question mark parameter workaround outlined above. I've also been using this with Dapper, but don't really think this is the cause as I think I was having these issues with the data reader API too. I'll try and put something together for you when I get the time. |
|
You don't really need that workaround, "question mark" parameters are supported out of the box: https://duckdb.net/docs/basic-usage.html#parameterized-statements Can you try if you get the exception on other platforms too? |
|
Ah yes, I meant I need this workaround to use Dapper as it only supports named parameters, generating them with names like Sure, I'll try and check it out in Windows as well! |
|
@ntsim Dapper supports so-called "pseudo-positional parameters". See if it helps in your case: DapperLib/Dapper#1952 (comment) |
|
Closing due to inactivity. |
|
Hey, @Giorgi I want to share my findings on this type of errors. The debugging session may throw one of two following exceptions: or Facts:
Possible cause: I suppose it is related to how debugger handles marshalling. Example place where it fails is There is a call to: [DllImport(DuckDbLibrary, CallingConvention = CallingConvention.Cdecl, EntryPoint = "duckdb_bind_parameter_index")]
public static extern DuckDBState DuckDBBindParameterIndex(DuckDBPreparedStatement preparedStatement, out int index, SafeUnmanagedMemoryHandle name);after which the Workaround: As you see, the issue is not in your code, but in debugger optimizations. |
|
@andriibratanin Thanks for the detailed investigation and for providing a workaround. Did you report the issue to JetBrains? |
|
@Giorgi, I've just created it in their YouTrack system, but it can take ages to fix... And, BTW, I was able to reproduce the issue in Visual Studio too. What I'd recommend you to do is place the related information on this issue on some page so it can no longer be a "show stopper"/"deal breaker" for those people trying DuckDb.NET and building PoCs. DuckDb is a rising star and you've done a lot of work ;) |
When running a query like:
When debugging in Rider (haven't tested in Visual Studio), an
AccessViolationExceptionseems to be consistently thrown upon executing the reader:No breakpoint is necessary for this to happen.
Not sure if this is an environment specific issue or not, but it's a bit of a showstopper to using named parameters if debugging doesn't work.
Environment
The text was updated successfully, but these errors were encountered: