Difference between return result code from open(): 25 vs 3?

Question

I'm debugging a Qt program using strace, and the open() function shows that :

open("../libPlayCtrl.so", O_RDONLY|O_CLOEXEC)

in the cases it returns 3 it seems work, but when it returns 25 it does not, and the libPlayCtrl.so is not loaded.

What's the difference? And how can I fix it?

The .so file is a 3rd party lib. And not only this one, I also use other 3rd libs, and they are from the same vender. Some other lib files get their open(...) = 3, and they seem work fine.

• Platform: Ubuntu 12.04 , 32bit.
• Qt4.8
• QtCreator 2.4.1
• Compiler: GCC

EDIT:

below is part of strace output, due to I changed the configuration, the location of .so file is different. And the succeeded .so file is a newer version of the lib from the vender.

Success Case: 15 clauses in total before it finally found .so file.

open("../lib/tls/i686/sse2/cmov/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/tls/i686/sse2/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/tls/i686/cmov/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/tls/i686/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/tls/sse2/cmov/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/tls/sse2/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/tls/cmov/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/tls/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/i686/sse2/cmov/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/i686/sse2/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/i686/cmov/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/i686/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/sse2/cmov/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/sse2/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/cmov/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("../lib/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = 3

Fail Case: ellipsis indicates there are about 95 open() clauses that all equal to -1(not found). As you can see it turned out this time, it became 30 when it finally found the .so file.

And the program showed an error from the lib (maybe other): "Failed to load player SDK".

.....
21:02:33 open("./sse2/cmov/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
21:02:33 open("./sse2/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
21:02:33 open("./cmov/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
21:02:33 open("./libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
21:02:33 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 30
21:02:33 open("/.../.../.../RemoteClient/lib/libPlayCtrl.so", O_RDONLY|O_CLOEXEC) = 30`

Answer 1

Go to the manual page for the open() system call, and you will find the explanation that the return value from open() is the number of the new, opened file descriptor.

After investing some more time in Google, you are certain to find an explanation that when a new file is opened, the kernel assigns the lowest available, unused, file descriptor to the opened file. That's all.

In conclusion, it doesn't matter whether open() returned 3 or 25, or 17, or 8. They all indicate that the file was opened successfully, and your suspicion that a different non-zero value indicates a problem of some kind is incorrect.

You may certainly have a problem of some kind with your application, but it does not have any direct relationship with this specific return value from open().

Now, the fact itself that sometimes you see open() returning 3, and sometimes 25 -- that indicates that there are several ways to reach this particular point in your application execution: with either no files open, other than the standard input, output, and error; or with at least 22 additional files, of some kind, opened already. It's entirely plausible that in the latter case your application did a lot more apparent work, involving opening 22 or more files before loading this library, and encountered a problem of some kind. But the actual problem itself has absolutely nothing to do with this specific system call.