#3643 Setting HOME var with putenv in windows causing problems

obsolete: 8.4.4
closed-invalid
5
2007-09-25
2007-02-14
No

I believe this also applies to 8.4.14

Under Windows XP, I was running into a SIGTRAP signal when initializing tcl. Under gdb, I tracked this down to when the HOME environment variable gets set using putenv.
Turning off USE_PUTENV seems to have alleviate this problem in a testing environment. I have yet to attempt using this in my target environment.

Discussion

  • Jeffrey Hobbs

    Jeffrey Hobbs - 2007-02-14

    Logged In: YES
    user_id=72656
    Originator: NO

    ??? There seem to be so many assumptions in this post that don't make sense. SIGTRAP on Windows? gdb? In the end, you should also be using Tcl_PutEnv.

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2007-02-14
    • status: open --> pending-invalid
     
  • Matthew Jimenez

    Matthew Jimenez - 2007-02-14
    • status: pending-invalid --> open-invalid
     
  • Matthew Jimenez

    Matthew Jimenez - 2007-02-14

    Logged In: YES
    user_id=897640
    Originator: YES

    Yes, SIGTRAP on windows (XP SP2). Yes, GDB (6.3). Code was compiled by gcc 3.4.2 (mingw-special)

    from GNU gdb 6.3 under "i686-pc-ming32"
    >>
    gdb: Target exception EXCEPTION_BREAKPOINT at 0x7c822583

    Program received signal SIGTRAP, Trace/breakpoint trap.
    0x7c822584 in ntdll!DbgUiIssueremoteBreakin () from ntdll.dll
    >>

    This started from the line "
    Tcl_SetVar2(interp, "env", "HOME", Tcl_DStringValue(&ds),
    TCL_GLOBAL_ONLY);
    " in tclWinInit.c:657

    and actually occurred when calling "putenv(p)" in the function TclSetEnv(name, value) in tclEnv.c:267

    I was not setting any tcl environment variables in my code.
    This all occurred as a result of calling Tcl_CreateInterp();

     
  • Donal K. Fellows

    • priority: 5 --> 8
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2007-09-11

    Logged In: YES
    user_id=72656
    Originator: NO

    I suspect something funny about how you integrate this. I am able to build with mingw-gcc 3.4.2 and run 'make test' without any problems (which of course creates a lot of interpreters). It fails in some glob tests, but nothing catastrophic.

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2007-09-11
    • priority: 8 --> 5
    • status: open-invalid --> pending-invalid
     
  • SourceForge Robot

    • status: pending-invalid --> closed-invalid
     
  • SourceForge Robot

    Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
  • Matthew Jimenez

    Matthew Jimenez - 2007-10-04

    Logged In: YES
    user_id=897640
    Originator: YES

    Sigh. I got hit by it again, and had to come back to this issue to remember what was causing it and a thought occurred to me. Was the make test being run from inside msys or a different shell where the HOME environment variable is set?

    I just found the issue seems to be avoidable if I set HOME and now I'm curious if the issue occurs elsewhere is HOME is unset.

    I'll follow up with some testing using the most current version locally. (Seems OK to keep the bug closed unless I get some interesting results.)

     
  • Matthew Jimenez

    Matthew Jimenez - 2007-10-04

    Logged In: YES
    user_id=897640
    Originator: YES

    Just ran make test under msys on tcl 8.4.16 with HOME, HOMEDRIVE, and HOMEPATH set and then again after unsetting them results seem to be good under both situations.

    So either the issue really is fixed or quite a bit harder to hit due to how we integrate it.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks