wfdb libraries crashing while accessing the wfdb files simultaneously (concurrent access)

[dhivya-pushparaj]

Team,

We are using libwfdb.so and libwfdbjava.so files to read wfdb files from java webservices. While making concurrent hits, the library and JVM crashing with the below error message.

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x00007fe9cd9457ff, pid=13476, tid=0x00007fe9c52f4700

JRE version: Java(TM) SE Runtime Environment (8.0_101-b13) (build 1.8.0_101-b13)

Java VM: Java HotSpot(TM) 64-Bit Server VM (25.101-b13 mixed mode linux-amd64 compressed oops)

Problematic frame:

C [libwfdb.so.10+0xd7ff] getskewedframe+0x259

Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

If you would like to submit a bug report, please visit:

http://bugreport.java.com/bugreport/crash.jsp

The crash happened outside the Java Virtual Machine in native code.

See problematic frame for where to report the bug.

--------------- T H R E A D ---------------

Current thread (0x00007fe9f0006800): JavaThread "ajp-nio-18009-exec-8" daemon [_thread_in_native, id=13618, stack(0x00007fe9c51f4000,0x00007fe9c52f5000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 128 (SI_KERNEL), si_addr: 0x0000000000000000

Registers:
RAX=0x6f2e74656e6f6974, RBX=0x00007fe9fc0068d0, RCX=0x00007fea2bcc35f9, RDX=0x6f2e74656e6f6973
RSP=0x00007fe9c52f0f10, RBP=0x00007fe9fc007d70, RSI=0x00007fe9fc00d2b0, RDI=0x00007fe9fc00d2b0
R8 =0xffffffffffffffff, R9 =0x0000000000000000, R10=0x0000000000000022, R11=0x0000000000000202
R12=0x0000000000000000, R13=0x00007fea00005b20, R14=0x0000000000000000, R15=0x0000000000000000
RIP=0x00007fe9cd9457ff, EFLAGS=0x0000000000010202, CSGSFS=0x0000000000000033, ERR=0x0000000000000000
TRAPNO=0x000000000000000d

We are trying to understand if wfdb libraries are thread safe and can it withstand simultaneous access?

Thanks!

[bemoody]

No, unfortunately, the library is not thread-safe. The present WFDB API is not really amenable to working with multiple records simultaneously, as you'll probably realize if you start trying to do it. If you imagine that two threads have opened different records simultaneously, then if you call getvec, which record are you reading from? I can see a couple of possible ways the library could be made thread-safe. 1. All of the library's internal data is attached to a single "WFDB handle". Instead of calling isigopen(rec, si, nsig), you'd call isigopen_r(handle, rec, si, nsig) and instead of getvec(v) you'd call getvec_r(handle, v). (Or something else less ugly than "_r".) The old API becomes a very thin wrapper around the new API; translating programs between the old and new APIs is fairly trivial. 2. Design an entirely new thread-safe API from the ground up, and make it easy to use but completely different from the old API. Opening a record creates a record handle that you would pass to other functions, etc. I'd be happy to do either of these things if they can be done in a clean, compatible, and maintainable way. Unfortunately I won't have time to implement #2 and probably won't even have time to implement #1 in the near future. (Patches are welcome, of course!) If you let me know what you're trying to accomplish, I may be able to suggest a strategy that would make sense.

[dhivya-pushparaj]

Thank you very much, @bemoody for responding with the options and I'm sorry for getting back late on this one.

Yes, both the options seem to require some work to be done at the level below the java services layer that we have built.

And to answer your question on what needs to be accomplished,

1. We have a web application which displays list of records and record data are retrieved from the wfdb files.
2. When the same record is being accessed by multiple users, we are getting into the issue.

Please let me know if I have enough information shared and any suggestions would be of great help here.

Thank you, once again!

[dhivya-pushparaj]

Hi Team,

We are just following up to see if we have patches expected to handle thread-safe applications, any sooner. As we have come half-way through with our implementation, it will help us plan our further works better.

Thank you!