Open walterlv opened 1 month ago
Tagging subscribers to this area: @tommcdon See info in area-owners.md if you want to be subscribed.
Hi @walterlv! Thanks for reporting this bug!
I didn't find any environment that doesn't have this issue.
Do you know if this issue reproduces on Windows?
Do you know if this issue reproduces on Windows?
Ahh nevermind this question as the repro is very specific to linux.
Do you know if the callback/debugging issue is specific to the libpulse API (e.g. does a standalone repo that uses callback from C++ to C# on Linux reproduce the issue)? I am curious if there is something specific to libpulse that is causing the problem, for example a difference in calling convention, etc...
@tommcdon I can repro this issues by @walterlv 's repo in my linux system. And I can sure it's not the libpulse bug, because I can repro this issues with https://github.com/Haltroy/CefGlue
I can not reproduce on Windows because I fail to run the libpulse on Windows... I mean I do not know if it can be reproduced on Windows.
Possible duplicate to https://github.com/dotnet/runtime/issues/102767. @hoyosjs
Thanks to my friend @kkwpsv, he helped me to find out more information about this issue.
@tommcdon This issue is quite different from #102767:
Let's see more details here.
Then,
thread backtrace all
and we that thread 3 .NET EventPipe
is stopped with signal SIGTRAP
signal SIGSEGV: address not mapped to object (fault address: 0xbafa13a0)
.The stack traces are shown as follows:
[UnmanagedCallersOnly]
private static unsafe void Callback(byte* sourceId, int isEnabled, byte level,
long matchAnyKeywords, long matchAllKeywords, Interop.Advapi32.EVENT_FILTER_DESCRIPTOR* filterData, void* callbackContext)
{
EventPipeEventProvider _this = (EventPipeEventProvider)GCHandle.FromIntPtr((IntPtr)callbackContext).Target!;
if (_this._eventProvider.TryGetTarget(out EventProvider? target))
{
_this.ProviderCallback(target, sourceId, isEnabled, level, matchAnyKeywords, matchAllKeywords, filterData);
}
}
@hoyosjs
Hi @walterlv and @lindexi,
We haven't been able to repro the exact issue from your repros yet, but the SIGSEGV
for the EventPipeEventProvider callback looks eerily similar to https://github.com/dotnet/runtime/issues/80666#issuecomment-2249343314, where the _gchandle used in the callback had been freed before the callback completes.
If the dotnet debugger is hitting the same EventPipeEventProvider Callback issue, then there is a partial fix already merged through https://github.com/dotnet/runtime/pull/106040 and a second PR https://github.com/dotnet/runtime/pull/106156 that is open
@mdh1418 Thank you. What VisualStudio version and dotnet version you use? And do you debug the application run on Linux?
Can I test the daily dotnet version which merged https://github.com/dotnet/runtime/pull/106040 ?
What VisualStudio version and dotnet version you use? And do you debug the application run on Linux?
We used the latest version of the C# extension in VS Code
Can I test the daily dotnet version which merged https://github.com/dotnet/runtime/pull/106040 ?
Yes - the daily builds from https://github.com/dotnet/sdk/blob/main/documentation/package-table.md contain the fix.
@tommcdon I test again with https://aka.ms/dotnet/9.0.1xx/daily/dotnet-sdk-linux-x64.tar.gz
.
There is no SIGSEV now. The process still exits with SIGTRAP.
I debugged it with lldb
. Here's the output:
Description
Note: Not all native callbacks cause this issue so I've written a minimal reproducible example below.
Reproduction Steps
Minimal reproducible example 1:
Reproducible example 2:
Expected behavior
The app should not crash when the dotnet debugger is attached.
Actual behavior
The app crashes with an output "Trace/Breakpoint Trap".
Regression?
I've only tested this on .NET 8.0.302
Known Workarounds
I've found several workarounds:
Note:
Debugger.IsAttached
property cannot detect the native debugger so I added alternative options--sleep <seconds>
and--skip-attach
for the minimal reproducible example above.Configuration
I didn't find any environment that doesn't have this issue.
Other information
dotnet tool install -g dotnet-sos
dotnet sos install
ulimit -c unlimited
echo "0x3F"> /proc/<pid>/coredump_filter
after the process starts and the pid is known.Trace/Breakpoint Trap (core dumped)
.lldb --core core TraceBreakpointTrapDemo