The TORCS Racing Board
Username: Password: Remember Me?
Lost Password Register
Author: firechief | Created: 2017-05-30 04:30:02
Subject: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
The problem occurs in MyRobot::AvoidOtherCars(). One of the arguments passed to this function is bool *lapper, but line 3252 says "lapper = false". This sets the pointer to zero instead of setting the value of the bool to false.

Later in the function, line 3460, is "*lapper = true" which triggers the segfault, as its an attempt to write to address 0x00000000.

The solution is to change line 3252 to *lapper = false.
Last Edited: 2017-05-30 06:40:04 by firechief
    Author: timfoden | Created: 2017-05-30 07:02:00
    Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
    Oops. Serves me right for changing the code so that the caller knows that the value will be changed (using a pointer rather than a reference.) I really should have been more careful.

    Cheers, Tim.
    Last Edited: 2017-05-30 07:02:00 by timfoden
      Author: firechief | Created: 2017-05-30 07:05:05
      Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
      Its all good :)

      Unfortunately I saw both Tiger & Mouse had problems in the first round of pit stops, which severely compromised their races - I'd be interested to know if other people saw the same thing.
      Last Edited: 2017-05-30 07:05:05 by firechief
        Author: timfoden | Created: 2017-05-30 08:52:09
        Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
        It wouldn't surprise me as the code to try to stop them from pitting at the same time is very new (wrote it yesterday)... I didn't have time to test it at all thoroughly.

        No matter, better to have cars in the race than not submit anything! :)

        [Aside: Only 8 teams? -- I thought (hoped) there'd be more.]

        Cheers, Tim.
        Last Edited: 2017-05-30 09:01:25 by timfoden
          Author: firechief | Created: 2017-05-30 09:11:21
          Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
          > Aside: Only 8 teams? -- I thought (hoped) there'd be more.

          Yeah that was a little disappointing, though there's nothing to stop people joining the competition during the season.

          Last year we had 20 cars for race one, but only 4 competitors (Bernhard, W-D, Danny and myself). I ran 4 teams, Danny had 3 and W-D two. This year, Danny & I only have 2 teams entered (we both wanted to leave room for new teams) while W-D has just the one, and this looks like the first season without a berniw on track - I'm speculating that Bernhard perhaps didn't have the time needed to adapt his robot for pro mode with tyre temps etc.

          On a more positive note, you've returned with 2 teams and Fabian's joined in. I do hope Jacob, Joe, Quinten and Rico will still decide to register despite missing the first race.
          Last Edited: 2017-05-30 09:11:21 by firechief
            Author: berniw | Created: 2017-05-31 21:52:45
            Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
            No, I have a simple version ready since long, helped me with testing;-) But because of some constant whining about my bot I decided to take a brake for a few races at least.

            Bernhard
            Last Edited: 2017-05-31 21:52:45 by berniw
              Author: firechief | Created: 2017-06-01 02:56:21
              Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
              Constant whining? Hmm. I think people were concerned if you didn't have time to work on it & just submitted an unmodified berniw_2004, as that'd be a wrecking ball in pro mode. Otherwise, yes I know I like to poke fun at the robot now & then in my pictorial reviews but that's meant to be humorous, not whining as such.

              Honestly, if you've updated your robot, I know I'd love to see it in action & I'd be very surprised if others didn't feel the same way.
              Last Edited: 2017-06-01 02:56:21 by firechief
    Author: dummy | Created: 2017-05-30 10:51:08
    Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
    Thanks Andrew for pointing to the bug.

    I only ran the race until the first pit stops and saw no problems with Tim's teams, but could be because there were big pileups with Fabian's cars and huge damages to everyone :)

    Rico is the helping hand of Fabian. I don't think he intends to race himself ;) But I hope the others will join for the next race.

    BTW: Very funny and professional paint jobs from both of you. Maybe that's the secret for fast cars and not the color as suggested last year ;)
    Last Edited: 2017-05-30 10:57:16 by dummy
    Author: wdbee | Created: 2017-05-30 18:45:05
    Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
    Thanks for this bugfix.

    Here I get another TORCS crash in addition. Tried to run the robots in debug mode, but the usr does not compile (in <portability.h> config.h is not found???).

    Running the race without usr shows that the mice and the tigers are spamming the console.

    All I can say about the crash is, that is caused by someone using the std::vector class.

    Wolf-Dieter
    Last Edited: 2017-05-30 18:45:05 by wdbee
      Author: timfoden | Created: 2017-05-30 21:40:18
      Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
      Sorry about the spam. In Utils.h there are the following definitions:

      #define DEBUGF GfOut
      #ifdef DEV
      #define LOGF printf
      #else
      #define LOGF GfOut
      #endif

      If you change the DEBUGF and LOGF to accept variable params but do nothing then the spam in debug mode should abate. e.g.:

      #define DEBUG(x, ...) do {} while(false)
      #define LOGF(x, ...) do {} while(false)


      Cheers, Tim.
      Last Edited: 2017-05-30 21:40:42 by timfoden
      Author: firechief | Created: 2017-05-31 02:33:44
      Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
      I hadn't tried compiling USR in debug for a long time.

      Two files have portability.h included - raceline.cpp and manual_override.cpp. Remove it from both, and in manual_override.cpp include the following lines at the top of the file under the includes...

      #ifdef WIN32
      #define snprintf _snprintf
      #endif

      Edit: A quick grep shows a single use of std::vector in dandroid/dummydrivers, and multiple uses of it in fa1
      Last Edited: 2017-05-31 02:35:20 by firechief
        Author: wdbee | Created: 2017-05-31 06:34:40
        Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
        Hi Andrew,

        you reported "fa1 crashes in my test race" in another post.
        I assume my crash is still caused by this issue.

        The std::vector class uses exceptions. The robots are DLLs/SOs, and an exception raised in a robot has to be catched in the robot code (the DLL). Handling exceptions in TORCS (calling the DLLs) is not possible.

        In addition, the WINDOWS Version of TORCS has a modified handling of memory allocation in debug mode. These modifications do not work for mixed use of alloc/free and new/delete.

        To run the race in debug mode you have to modify TORCS to not use the extened debug checks defined in tgf.

        Using std::xxx is not a good idea for TORCS. In the past I used Tim's Dynamic Array class instead and never had issues with it.

        Cheers

        Wolf-Dieter

        Last Edited: 2017-05-31 06:35:10 by wdbee
    Author: timfoden | Created: 2017-05-31 21:03:42
    Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
    Oh, BTW, I fixed a bug in Mouse that's also in Axiom in LinePath::CalcFwdAbsK(). It causes VS to complain ("Windows has triggered a breakpoint in wtorcs.exe.") every time it's run under the debugger as it writes off the end of an array.

    All uses of NSEG in that function need to be changed to (NSEG - 1).

    e.g. this:

    i = (NSEG / step) * step;

    to this:

    i = ((NSEG - 1) / step) * step;

    and in another 2 places.

    Cheers, Tim.
    Last Edited: 2017-05-31 21:07:15 by timfoden
      Author: firechief | Created: 2017-06-01 02:57:25
      Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
      Many many thanks! That breakpoint has really annoyed me & I could never track it down, its great to get that fixed :)

      Question though - wouldn't it be easier to just change the first line in the function from:

      const int NSEG = m_pTrack->GetSize();

      to:

      const int NSEG = m_pTrack->GetSize() - 1;

      ?
      Last Edited: 2017-06-01 03:00:03 by firechief
        Author: timfoden | Created: 2017-06-01 07:19:16
        Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
        :)

        Yes, of course that would work too... but it breaks an implied contract that NSEG holds the number of segments in the track, so if later there were changes to be made the fact that this NSEG isn't actually like all the other NSEGs in the code may also cause a bug.

        Cheers, Tim.
        Last Edited: 2017-06-01 07:19:16 by timfoden
          Author: firechief | Created: 2017-06-01 09:26:57
          Subject: Re: Segfault in mouse_2017 and tiger_2017 (I've included the fix)
          Yes that's a good point. Here's my compromise...

          const int NSEGm1 = m_pTrack->GetSize() - 1;

          (NSEG minus 1)

          :)
          Last Edited: 2017-06-01 09:26:57 by firechief