interpreter limits

Discussion in 'Python' started by Joseph T. Bore, Apr 13, 2004.

  1. I'm embedding python in my app, and I'm using it as a scripting
    language for it, everything works great.

    My only concern is how to handle the possibility that a user
    accidentally puts an infinite loop in the code that gets called by the
    app.

    Something as simple as a function that has as it's body:

    while 1:
    pass

    would require the application to be killed. Hopefully this will
    rarely happen, but it's a *real* and unacceptable possibility.

    Looking around, it seems that this has occasionally been brought up by
    others, but no solution has been arrived at. I even looked at grail,
    figuring that perhaps there were some controls put in for the python
    applets it would load, but no luck there either it seems.

    I dont know a heck of a lot about the implementation of the
    interpreter/vm but would it be possible to implement exec or eval with
    an optional argument, that argument would be a maximum number of byte
    codes the interpreter would execute before throwing an exception.

    this would eliminate the out of control case where a function runs
    the above code and never returns. you could make the value large
    enough to handle just about everything except for infinite loops.

    something like:

    try:
    exec(codeToExecute, maxTicks = 100000)
    except InterpreterLimitReached:
    print "your code ran too long"

    Anyone have any idea if this is at all implementable?

    jbore
    Joseph T. Bore, Apr 13, 2004
    #1
    1. Advertising

  2. Joseph T. Bore wrote:

    > I dont know a heck of a lot about the implementation of the
    > interpreter/vm but would it be possible to implement exec or eval with
    > an optional argument, that argument would be a maximum number of byte
    > codes the interpreter would execute before throwing an exception.


    Interesting. I know it's not of any help but 'back then',
    most MUD engines did exactly this (at least, LP and MudOS did).
    When a user-written module ran too long, it was aborted, to
    avoid hanging the mud :)

    --Irmen
    Irmen de Jong, Apr 13, 2004
    #2
    1. Advertising

  3. Irmen de Jong <> writes:

    > Interesting. I know it's not of any help but 'back then',
    > most MUD engines did exactly this (at least, LP and MudOS did).
    > When a user-written module ran too long, it was aborted, to
    > avoid hanging the mud :)


    Indeed. In my case MOO is where I got the idea from. moop is also a
    side interest of mine where this becomes very important.

    Any idea if it's possible? should I write a PEP?

    jb
    Joseph T. Bore, Apr 13, 2004
    #3
  4. Joseph T. Bore wrote:

    > Any idea if it's possible? should I write a PEP?


    Can't you do something smart with signals, threads, alarm() and kill() ?
    Like running the code in a worker thread, where the main thread
    keeps track of how long it has been running and if not finished
    within a certain time, kill() it.
    Or use alarm() to get signaled after some time, then kill it in
    the signal handler.

    --Irmen
    Irmen de Jong, Apr 13, 2004
    #4
  5. Irmen de Jong <> writes:
    > Or use alarm() to get signaled after some time, then kill it in
    > the signal handler.


    I hadnt thought about using alarm like that, I have to experiment

    jb
    Joseph T. Bore, Apr 13, 2004
    #5
  6. Joseph T. Bore

    Paul Rubin Guest

    Irmen de Jong <> writes:
    > Can't you do something smart with signals, threads, alarm() and kill() ?
    > Like running the code in a worker thread, where the main thread
    > keeps track of how long it has been running and if not finished
    > within a certain time, kill() it.


    How do you kill a thread from another thread? I don't know of any way
    to do that.

    Maybe it's safest to run the user script in a separate process and
    communicate through a socket or through shm. That allows using the
    normal OS features for resource limits, file protection, etc.
    Paul Rubin, Apr 13, 2004
    #6
  7. Joseph T. Bore wrote:

    >
    > Indeed. In my case MOO is where I got the idea from. moop is also a
    > side interest of mine where this becomes very important.
    >
    > Any idea if it's possible? should I write a PEP?


    You can impose such limits with a trace hook in the thread running the
    code.

    HTH,
    Martin
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=, Apr 13, 2004
    #7
  8. Joseph T. Bore

    djw Guest

    Paul Rubin wrote:

    > Irmen de Jong <> writes:
    >
    >>Can't you do something smart with signals, threads, alarm() and kill() ?
    >>Like running the code in a worker thread, where the main thread
    >>keeps track of how long it has been running and if not finished
    >>within a certain time, kill() it.

    >
    >
    > How do you kill a thread from another thread? I don't know of any way
    > to do that.
    >
    > Maybe it's safest to run the user script in a separate process and
    > communicate through a socket or through shm. That allows using the
    > normal OS features for resource limits, file protection, etc.

    My exploration into threads indicated that you can't kill one thread
    from another.

    -Don
    djw, Apr 14, 2004
    #8
  9. Joseph T. Bore

    Peter Hansen Guest

    djw wrote:

    > Paul Rubin wrote:
    >
    >> Irmen de Jong <> writes:
    >>
    >>> Can't you do something smart with signals, threads, alarm() and kill() ?
    >>> Like running the code in a worker thread, where the main thread
    >>> keeps track of how long it has been running and if not finished
    >>> within a certain time, kill() it.

    >>
    >>
    >>
    >> How do you kill a thread from another thread? I don't know of any way
    >> to do that.
    >>
    >> Maybe it's safest to run the user script in a separate process and
    >> communicate through a socket or through shm. That allows using the
    >> normal OS features for resource limits, file protection, etc.

    >
    > My exploration into threads indicated that you can't kill one thread
    > from another.


    http://www.strakt.com/docs/os03_threads_interrupt.pdf has some info
    about an approach (via a C extension only) which can be used in 2.3
    to do it.
    Peter Hansen, Apr 14, 2004
    #9
  10. There is probably a better solution but this worked for me, thanks
    Irmen!

    jb

    ----------------------------------------
    import signal

    def alarmHandler(signum, frame):
    raise TimeExceededError, "Your command ran too long"

    def infinite():
    while 1:
    pass

    #
    # code to wrap a function call which may take too long...
    #
    signal.signal(signal.SIGALRM, alarmHandler)
    signal.alarm(1)
    try:
    # call a function that never returns
    infinite()
    except TimeExceededError:
    print "code must have gone crazy..."
    signal.alarm(0)
    ----------------------------------------
    Joseph T. Bore, Apr 14, 2004
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jack
    Replies:
    0
    Views:
    6,084
  2. Ashish
    Replies:
    1
    Views:
    3,140
    Natty Gur
    Nov 19, 2003
  3. Jerry Camel

    File Upload Limits

    Jerry Camel, Feb 20, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    375
    Ken Cox [Microsoft MVP]
    Feb 21, 2004
  4. Joe Van Meer
    Replies:
    2
    Views:
    631
    Peter O'Reilly
    May 5, 2004
  5. Replies:
    3
    Views:
    754
    Ziga Seilnacht
    Jan 3, 2007
Loading...

Share This Page