check_nfs4_error NULL dereference

[zhiburt]

Hi @sahlberg

I was hacking around to make sense of a different issue I've encountered (see afterwords). And then switching to master I've got this.

Seemly restoring back the res check fixes it. But the real source of problem I can't tell.

https://github.com/sahlberg/libnfs/blob/888c1e086fae86d204067be15dd4d47ccc142123/lib/nfs_v4.c#L364

#0  check_nfs4_error (nfs=nfs@entry=0x7ffff7fc5f50, status=0, data=data@entry=0x7ffff7fb4700, command_data=command_data@entry=0x0, op_name=op_name@entry=0x7ffff7a301c1 "CONNECT")
    at nfs_v4.c:366
#1  0x00007ffff791886b in nfs4_mount_1_cb (rpc=0x7ffff7faa430, status=<optimized out>, command_data=<optimized out>, private_data=0x7ffff7fb4700) at nfs_v4.c:1705
#2  0x00007ffff7904426 in rpc_connect_program_5_cb (rpc=0x7ffff7faa430, status=<optimized out>, command_data=0x0, private_data=0x7ffff7fc7f40) at libnfs.c:991
#3  0x00007ffff791e9d3 in rpc_process_reply (rpc=0x7ffff7faa430, zdr=<optimized out>) at pdu.c:1037
#4  0x00007ffff7920421 in rpc_process_pdu (rpc=rpc@entry=0x7ffff7faa430, buf=0x7ffff7fb4320 "$\355\347\r", size=size@entry=24) at pdu.c:1323
#5  0x00007ffff7922094 in rpc_read_from_socket (rpc=0x7ffff7faa430) at socket.c:889
#6  rpc_service (rpc=0x7ffff7faa430, revents=revents@entry=1) at socket.c:1310
#7  0x00007ffff7903ed8 in nfs_service (nfs=nfs@entry=0x7ffff7fc5f50, revents=revents@entry=1) at libnfs.c:226
#8  0x00007ffff790805f in wait_for_nfs_reply (nfs=nfs@entry=0x7ffff7fc5f50, cb_data=cb_data@entry=0x7fffffffd9c0) at libnfs-sync.c:286
#9  0x00007ffff790818a in _nfs_mount (nfs=nfs@entry=0x7ffff7fc5f50, server=server@entry=0x7ffff7fb4450 "127.0.0.1", export=export@entry=0x7ffff7fc7f10 "/mind_test_nfs_share")
    at libnfs-sync.c:335
#10 0x00007ffff7908d78 in nfs_mount (nfs=0x7ffff7fc5f50, server=server@entry=0x7ffff7fb4450 "127.0.0.1", export=export@entry=0x7ffff7fc7f10 "/mind_test_nfs_share")
    at libnfs-sync.c:356

---

About the issue I've mentioned. Can you tell what is recommended, to open 2 files (nfs_open2) use 1 struct nfs_context or 2 per file? I mean shall struct nfs_context be used as a singleton or per thread or per file? What your thoughts here?

Take care

[sahlberg]

Thanks for the report. I will look into this in the coming weekend.

As for multithreading and contexts. You can use a single context for as many different files you open. But by default libnfs will compile without multithreading support. (I am more a fan of async eventdriven designs than multiuthreading)

Compiling without multithreading makes it faster, no lokcing an no context switches, but at the expense that async designs are often harder and less convenient to use.

I have added support for multithreading, bot for native win32 as well as pthreads. For linux configure with --enable-phtread Also see README.multithreading and the examples.

Without pthread support you would need to create one nfs context per thread. With pthread support compiled in, you need to create the service thread for managing the socket (see the examples) but then you can use the same context across all the threads. (this mostly adds the locking when accessing lists and also having a per-thread storage for nfs_set/get_error())

In short, if you just want something that works, configure with --enable-pthread and recompile the library. If you need the highest possible performance, even if it makes writing the application a lot more painful: configure WITHOUT --enable-pthread, then if you are multithreaded create one context private to each of your application threads and only use the async api.