Inconsistent Accessibility Error with the Following C# Code. Why

layout next shows [ No Source Available ]

No Source Available

The error means literally that: GDB doesn't know where the source for the current program location is.

There are several possible reasons:

• you have not started the program yet
• you built your program without debugging info (without -g flag)
• you are stopped inside a system library
• you moved the source to a different location after the program was built

No source available for libstdc++-6...

You can ignore the "No source available" message. You get this message because you are using the debugger to look at stack frames which are executing functions in the standard library, and the source code for the standard library is not available. It is okay that the source is unavailable, because the bug is probably not in the standard library anyway.

It is phenomenally rare to encounter bona fide bug in your toolchain.

How to read a stack trace

I created a small program that crashes on my system.

#include <vector>
#include <algorithm>

int main() {
    std::vector<int> v { 9, 8, 7, 6, 5, 4, 3 };
    std::sort(std::begin(v), std::begin(v) + 16);
    return 0;
}

When I run it in gdb, I get the following stack trace:

#0  0x00007ffff7246107 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff72474e8 in __GI_abort () at abort.c:89
#2  0x00007ffff7284044 in __libc_message (do_abort=do_abort@entry=1, 
    fmt=fmt@entry=0x7ffff7376c60 "*** Error in `%s': %s: 0x%s ***
")
    at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff728981e in malloc_printerr (action=1, 
    str=0x7ffff7376e20 "free(): invalid next size (fast)", ptr=<optimized out>)
    at malloc.c:4996
#4  0x00007ffff728a526 in _int_free (av=<optimized out>, p=<optimized out>, 
    have_lock=0) at malloc.c:3840
#5  0x0000000000401456 in __gnu_cxx::new_allocator<int>::deallocate(int*, unsigned long) ()
#6  0x00000000004010ca in std::allocator_traits<std::allocator<int> >::deallocate(std::allocator<int>&, int*, unsigned long) ()
#7  0x0000000000400dba in std::_Vector_base<int, std::allocator<int> >::_M_deallocate(int*, unsigned long) ()
#8  0x0000000000400b95 in std::_Vector_base<int, std::allocator<int> >::~_Vector_base() ()
#9  0x0000000000400a6b in std::vector<int, std::allocator<int> >::~vector() ()
#10 0x0000000000400878 in main ()

You can see that frame #10 is in my code, but frames #0-9 are in the standard library. That's relatively normal. You'll also notice that the crash occurred after the incorrect code has finished executing: the call to std::sort() is what causes the crash, but the crash doesn't happen until main() returns.

Debugging crashes can be pretty tricky.

Tools for finding the error

You are using MinGW, which is GCC, which means you might have access to the address sanitizer. Try adding -fsanitize=address to your compilation and linking flags for debug builds.

When I compile my test program with -fsanitize=address, the program crashes in std::sort(), which is much closer to where the actual error is in main(). The address sanitizer will make your program crash more quickly so it will be easier to debug.

A similar tool is Valgrind.

Where is the error?

I can only guess, because I can't see any of your source code. But it looks like there is a bug in the constructor for Binary, or maybe a global variable with type Binary is constructed in the wrong way. Remember that global variables may be initialized in any order, so your code may crash if it uses any global variables which haven't been initialized yet. This is an extremely common source of errors in C++ programs.

No Source available

f:\dd\ndp\fx\src\... is the path to the source file on the machine that the .Net Framework was compiled on.

Go to Tools, Options, Debugging, Symbols, and select Only specified modules.

Also, uncheck Enable source server support in Debugging/General.

No source available in Eclipse

For those who have this issue in the future.

The problem comes from using a new version of GCC (GCC 8.1) and an older version of GDB (GDB 7.3)

GCC is putting out a new version of debug symbols that the old version GDB does not know how to deal with. I added flags to GCC to produce older dwarf symbols:

-ggdb -gdwarf-3

Here is the documentation for those flags

Why gdb complain to me that No Source Available (with g++ -ggdb3)

Why gdb complain to me that No Source Available (with g++ -ggdb3)

Because you are stopped inside libstdc++, which was built in a temporary directory (here /build/gcc/src/gcc-build/...) and that directory is not present on your machine.

It is exceedingly unlikely that you actually need to look at the source of operator<<(), but if you really do want to do that, install GCC sources, and use (gdb) directory to point GDB to the relevant sources.

No Source Available while debugging

Not sure if its a typo but you have the directory as ASODNSF rather than ASPDNSF in your path.

The applogic.cs file certainly does live in the ASPDNSFCore files. Make sure that you have copied the parent folder over instead of just the root (Web) folder. This, along with the other source code files, are in the directory above.

If that still fails then login to your account at Vortx (AspDotNetStoreFront's site) and download the full source files and copy them over. The source code files that live in the parent directory are really just for reference as rebuilding the library will amend the dll files that sit within the root (web) folder.

And obviously make sure that the bindings within IIS on the machine you copied it to also point to the correct path.

---

Related Topics