• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 1261 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS v5.4 on Linux, getpwuid_r problem

Stefan Rink
Prodigy 40 points

Other Parts Discussed in Thread: CCSTUDIO

Hi,

when installing CCS v5.4 in our lab environment, I have the problem that getpwuid_r reports an unknown user ID although the user is perfectly set up and other applications can resolve this well.
Subsequently, eclipse tries to create the workspace and many other files and directories below /home/user/?/... (note the question mark).
Eclipse behaves strangely thereafter, for example it tries to load a nonexistant file /home/artifacts.xml (with a java exception/stacktrace on stderr).
Furthermore, it is not possible to connect to a debugger (Error -2160 suggesting a "corrupt application file", which was previously discussed here in other threads).

This happens for all users which come in by LDAP (and have a NFS/automounter-mounted home, but that should not be an issue).
For local users (like root or other locally-created users) this does not happen. Not the question mark, not any other of the problems described here.
So this is definitely NOT a permission problem.

Googling a little on this problem hints that CCS might have used the getpwuid_r API incorrectly, which leads to the failure described above.
As a workaround, the same post recommends installing nscd, which tweaks the getwpuid_r call to enable proper operation.

However, this only hides the (presumed) bug in CCS.

Could somebody comment on this problem?

Regards,

Stefan

  • 0
    TI__Genius 15710 points

    Hello Stefan, 

    CCS is based on Eclipse which uses java. Hence CCS uses java system property "user.home" to find out users home directory. I am not sure which exact method java uses to find user's home directory when it configures user.home. However, it seems that there have been few others that ran into this issue. I found 

    http://stackoverflow.com/questions/1503284/java-system-getpropertyuser-home-returns

    First comment includes a simple java test that prints out java system properties. 

    This bug appears to match your description exactly, but it seems that the bug was closed. We can't use 64bit jvm in CCS due to many other libraries being 32 bit. 

    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6972329

    I can't reproduce this issue locally, hence I can't try this out, but it might be worthwhile to try using newer JRE, (it would need to be 32-bit) and you would need to replace the JRE in CCSInstallroot\ccsv5\eclipse directory.

    I am also guessing that since this is a lab machine, then CCS is installed to be shared and its installation directory might be non-writable by users. If this is the case, then one option to try out is to explicitly specify a different configuration area. Configuration area is used by eclipse to store machine local runtime generated settings. If the installation folder is not-writable then user.home is used to create a user specific configuration area. There is a command line parameter that could be used to overwrite this. 

    ./ccstudio -configuration /PathToUserHomeDir/ccs/configuration

    Martin

  • 0 in reply to MartinS
    Prodigy 40 points

    Hello Martin,

    thanks for your hints. However, this isn't a java problem. The actual problem already happens before ccstudio binary starts java, which can be seen when reading strace output. ccstudio prints on stderr:

    (ccstudio:9390): GLib-WARNING **: getpwuid_r(): failed due to unknown user id (31546)

    But the root cause is deeper, in libnss-ldap.

    Some debugging with our lab administration revealed that ia32-libs (the 32bit support-libraries which were installed on this 64bit system) did not use the nslcd (Note: nslcd, not nscd) stub version of libnss_ldap.so.2 (which would have worked perfectly), but rather tried to use the "real" libnss-ldap approach, which was destined to fail.
    After hacking together a better version of ia32-libs package, the problem was solved.

    Another solution would be to use LD_PRELOAD to preload the "better" version of libnss-ldap.so.

    Yet another solution would be to additionally install nscd. Note that this rather hides than solves the problem.
    However, nscd has a few issues and starts failing where one would least expect it.

    So went for the modified ia32-libs approach.

    Anyhow, my problem is solved now. Thanks for trying to help!

    Regards,
    Stefan 

  • 0 in reply to Stefan Rink
    Prodigy 90 points

    Would you mind saying which libraries you added/removed in the ia32-libs package? I'm seeing the same issue and would like to correctly fix it.

    Thanks.

  • 0 in reply to wylder
    Prodigy 40 points
    Hi wylder,

    since this is only about ensuring that ccstudio (and other applications too) uses the "proper" (nslcd) version of libnss_ldap, this is what you need to supply.
    You can do this by using LD_PRELOAD, or by using a repackaged ia32-libs package.

    Or did I misunderstand you? In that case, please rephrase your question.


    Regards, Stefan