Opened 4 years ago

Last modified 4 years ago

#13362 new bug

Conditional breakpoints in debugger are erratic

Reported by: calvinb Owned by: anevilyak
Priority: normal Milestone: Unscheduled
Component: Applications/Debugger Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


While I can set breakpoints such as "handle != 0x3" or "0" and they evaluate as expected, but breakpoints like "size == 16" won't - they simply always evaluate as true even if the variable display shows this to be false. This is on hrev50988.

To replicate this, I built Mono, and set a breakpoint on mono/metadata/w32file-unix.c line 1621 with a condition of "size == 16" - you should see it break on different values of "size."

Change History (9)

comment:1 by anevilyak, 4 years ago

Pure curiosity in case it matters, what type of variable is size in this case?

comment:2 by anevilyak, 4 years ago

Come to think of it, in case the expression evaluator is hitting an error, it might be interesting to know what the result is if, when stopped at this breakpoint, you open up Tools -> Evaluate Expression, and ask to evaluate the same thing manually there.

comment:3 by calvinb, 4 years ago

size is an unsigned 32-bit integer. It displays fine in the variable window. If I use the expression evaluator, it gives me expected results. (i.e: where size = 1088, size == 16 is 0, size == 1088 is 1)

comment:4 by anevilyak, 4 years ago

Interesting, that would seem to rule that part out, which surprises me. In any case, I'll try to reproduce this with a simplified test case. If that doesn't replicate the issue, is mono buildable for Haiku directly from their github repo, or are there some additional steps needed? Also, are you able to supply a sample C# program that triggers the above code?

comment:5 by calvinb, 4 years ago

My branch for Haiku support (partial - there still are critical runtime issues that prevent the C# compiler from compiling) has been merged, so do ./ --with-csc=mcs; make on upstream Mono (using gcc5) - the C# compiler is written in C#, so it'll used a precompiled compiler to do so. (To effectively attach the debugger, I recommend editing runtime/mono-wrapper.)

Last edited 4 years ago by calvinb (previous) (diff)

comment:6 by anevilyak, 4 years ago

Thanks! I'll see what I can do this weekend, and let you know if I run into any issues/have any additional questions.

comment:7 by anevilyak, 4 years ago

A question: I have mono built as indicated via the steps above, but it appears that at least for the resulting configuration, BLKGETSIZE64 has not been defined, and consequently line 1621 is not accessible for a breakpoint. Does any special option need to be set to define that? (FWIW, this is on a 32-bit build).

in reply to:  7 comment:8 by calvinb, 4 years ago

Oh, I had to hack the config.h file a bit to disable large file support on x86 - it had some issues with the runtime I'm still debugging.

comment:9 by anevilyak, 4 years ago

I seem to have another problem that's actually preventing that function from ever getting hit at all. When attempting to run make, it appears to consistently be dying while trying to build mcs, with output like the following:

*** The runtime 'mono' doesn't appear to be usable.
*** Trying the 'monolite' directory.

Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.


Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.

build/profiles/basic.make:112: recipe for target 'build/deps/basic-profile-check.exe' failed

Any ideas?

Note: See TracTickets for help on using tickets.