System.NullReferenceException on Raspberry PI - how to debug?

[sandreas]

Hey there,

I tried SharpAudio on Raspberry PI and got an Exception. I already installed openal:

ldconfig -p | grep openal
	libopenal.so.1 (libc6,hard-float) => /lib/arm-linux-gnueabihf/libopenal.so.1

I think, that SharpAudio might fail to load the library for some reason, but unfortunately I have no idea how to debug this...

• The wav file exists
• openal is installed
• libopenal.so.1 exists

Here is the code I used:

var soundFile = "testing.wav";
if (!File.Exists(soundFile))
{
    Console.WriteLine(soundFile + " does not exist");
}
else
{
	var engine = AudioEngine.CreateDefault();
	var soundStream = new SoundStream(File.OpenRead(soundFile), engine);
	soundStream.Play();

	var timer = new Stopwatch();
	timer.Start();
	while (soundStream.IsPlaying && timer.ElapsedMilliseconds < 5000)
	{
		Thread.Sleep(50);
	}
	soundStream.Stop();
}

And the exception:

System.NullReferenceException: Object reference not set to an instance of an object.
   at SharpAudio.BufferChain..ctor(AudioEngine engine)
   at SharpAudio.Codec.SoundSink..ctor(AudioEngine audioEngine, Submixer submixer, ISoundSinkReceiver receiver)
   at SharpAudio.Codec.SoundStream..ctor(Stream stream, AudioEngine engine, Submixer mixer)
   at App.Run(String deviceNode)

Could you please help me out again? :-) Thank you

[Devinyl]

I have the same problem, but could solve it

Tl;dr

fix it by adding a symbolic link to libdl.so.2 as the dotnet framework is not probing for libdl.so.2: sudo ln -s /usr/lib/aarch64-linux-gnu/libdl.so.2 /usr/lib/aarch64-linux-gnu/libdl.so

Explanation

if you attribute a file for interop the dotnet framework is probing the following paths and *.so names: Output from LD_DEBUG=libs:

find library=libdl.so [0]; searching 1875: search cache=/etc/ld.so.cache 1875: search path=/lib/aarch64-linux-gnu:/usr/lib/aarch64-linux-gnu:/lib:/usr/lib (system search path) 1875: trying file=/lib/aarch64-linux-gnu/libdl.so 1875: trying file=/usr/lib/aarch64-linux-gnu/libdl.so 1875: trying file=/lib/libdl.so 1875: trying file=/usr/lib/libdl.so 1875: 1875: find library=liblibdl.so [0]; searching 1875: search cache=/etc/ld.so.cache 1875: search path=/lib/aarch64-linux-gnu:/usr/lib/aarch64-linux-gnu:/lib:/usr/lib (system search path) 1875: trying file=/lib/aarch64-linux-gnu/liblibdl.so 1875: trying file=/usr/lib/aarch64-linux-gnu/liblibdl.so 1875: trying file=/lib/liblibdl.so 1875: trying file=/usr/lib/liblibdl.so 1875: 1875: find library=libdl [0]; searching 1875: search cache=/etc/ld.so.cache 1875: search path=/lib/aarch64-linux-gnu:/usr/lib/aarch64-linux-gnu:/lib:/usr/lib (system search path) 1875: trying file=/lib/aarch64-linux-gnu/libdl 1875: trying file=/usr/lib/aarch64-linux-gnu/libdl 1875: trying file=/lib/libdl 1875: trying file=/usr/lib/libdl 1875: 1875: find library=liblibdl [0]; searching 1875: search cache=/etc/ld.so.cache 1875: search path=/lib/aarch64-linux-gnu:/usr/lib/aarch64-linux-gnu:/lib:/usr/lib (system search path) 1875: trying file=/lib/aarch64-linux-gnu/liblibdl 1875: trying file=/usr/lib/aarch64-linux-gnu/liblibdl 1875: trying file=/lib/liblibdl 1875: trying file=/usr/lib/liblibdl

And that's why the issue looks like it can find the libopenal.so.1, but it fails already earlier when trying to load libdl.so.1. On the x86_64 ubuntu there are the following entries in the ldconfig:

libdl.so.2 (libc6,x86-64, OS ABI: Linux 3.2.0) => /lib/x86_64-linux-gnu/libdl.so.2
libdl.so (libc6,x86-64, OS ABI: Linux 3.2.0) => /lib/x86_64-linux-gnu/libdl.so
libdl.so (libc6,x86-64, OS ABI: Linux 3.2.0) => /usr/lib/x86_64-linux-gnu/libdl.so

and on the raspberry with dietpi os (Bullseye):

libdl.so.2 (libc6,AArch64, OS ABI: Linux 3.7.0) => /lib/aarch64-linux-gnu/libdl.so.2

How to debug

1. Use LD_DEBUG=libs in fron of the executable, this will tell you about loading native libraries, not .net libraries example: LD_DEBUG=libs /home/dietpi/<yourProgram> 2> output.txt
2. Use the strace functionality about open files: example: sudo strace -f -t -e trace=file ./SharpAudio.Sample -i "../Music/track1.mp3" 2> outputStrace.txt

Finally it showed that it was not able to load the libdl.so.2 As shown in the strace:

[pid 2463] 23:43:29 openat(AT_FDCWD, "/home/dietpi/test/libdl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 2463] 23:43:29 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 33 [pid 2463] 23:43:29 openat(AT_FDCWD, "/lib/aarch64-linux-gnu/libdl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 2463] 23:43:29 openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/libdl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 2463] 23:43:29 openat(AT_FDCWD, "/lib/libdl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 2463] 23:43:29 openat(AT_FDCWD, "/usr/lib/libdl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 2463] 23:43:29 openat(AT_FDCWD, "/home/dietpi/test/liblibdl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 2463] 23:43:29 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 33 [pid 2463] 23:43:29 openat(AT_FDCWD, "/lib/aarch64-linux-gnu/liblibdl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 2463] 23:43:29 openat(AT_FDCWD, "/usr/lib/aarch64-linux-gnu/liblibdl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 2463] 23:43:29 openat(AT_FDCWD, "/lib/liblibdl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 2463] 23:43:29 openat(AT_FDCWD, "/usr/lib/liblibdl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [pid 2463] 23:43:29 openat(AT_FDCWD, "/home/dietpi/test/libdl", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

[sandreas]

@Devinyl Wow, that is an awesome post. You, sir, deserve a cookie. Thank you very much, I'll try it in the next days...

[sandreas]

@Devinyl It worked. You saved me a lot of headache. Thank you very much...

@feliwir I would like to leave this issue open, because I think it would definetely be worth it to:

• Improve the documentation with a section Troubleshooting
• Improve the possibilities of logging / debugging in these edge cases.

What do you think?

[feliwir]

@sandreas Sure sounds good. I'd appreciate of either one of you could contribute these things. I'm not a macOS user and i couldn't test things myself