NamedPipe errors / maximum recursion depth exceeded

[skribb]

Also known as: RuntimeError: maximum recursion depth exceeded while calling a Python object

I think this may have started with K's Cli.py that he provided to me but i'm not sure. I've gotten this error now the past 2 days, not really sure what causes it:

This is just a snippet because the error log repeats the same error for several hundred lines (AFAIK only caused by firing 1-2 actions)

Code: Select all

  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "C:\Program Files (x86)\EventGhost\eg\NamedPipe.py", line 268, in send_message
    return send_message(msg)
  File "<string>", line 10, in __init__
RuntimeError: maximum recursion depth exceeded while calling a Python object

any clues?

[kgschlosser]

need to see the very top of it to know what the actual error is.

Let me do this. I am going to hunt down the version i did up with what I think resolves any problems with it. I will be back later today and i will see if i can find it.

[skribb]

2 things


1. Wow... i have NO memory of writing this thread at all. hahahah goddamn

2. here ya go, it's too much to fit (6000 lines) into a post so pasted it at https://paste.ofcode.org/BBmabFNRNsRMUHXHAFVAuR , it will expire in 1 week FYI

[skribb]

need to see the very top of it to know what the actual error is.

Let me do this. I am going to hunt down the version i did up with what I think resolves any problems with it. I will be back later today and i will see if i can find it.

Please note

I reverted to the original Cli.py of 05 rc4. Today I got the same error with gazillion lines of NamedPipe stuff.

[Snowbird]

I'm sorry to say but this feature is useless, unusable in its current state, so don't waste your time with it, I tried many things with no success.

[skribb]

I'm sorry to say but this feature is useless, unusable in its current state, so don't waste your time with it, I tried many things with no success.

What "feature" are you referring to? this error has occurred to me quite randomly so I don't even know what type of macro/event causes it to occur.

[Snowbird]

I'm talking about firing events from the command line, with the -event switch, it produces that error, is this your case ? are you firing events from the command line from time to time ?

[skribb]

I'm talking about firing events from the command line, with the -event switch, it produces that error, is this your case ? are you firing events from the command line from time to time ?

All the time, and yeah I just noticed!

just now, i did this command

Code: Select all

"C:\Program Files (x86)\EventGhost\EventGhost.exe" -event winamp_next

and got the error

EIDT: now i am converting video files which means the CPU is fully taxed. During this time I have gotten the NamedPipe error much more often than usual. I draw the conclusion that these errors are somehow related to processor threads/performance?

[Snowbird]

Kevin will tell you that he has tested hundreds of events per second without any hiccups I believe him, but as for me (and now for you apparently) it simply doesn't work fine all the time... That's too bad because it's a neat feature and very useful but unfortunately unusable... I abandoned the idea of using it, you are probably going to do the same

[kgschlosser]

I have worked on this many times. If you guys state there is an issue with it there is. I am trying to replicate the problem to locate the problem..

and Snowbird you know first hand how many times i have messed with it making the thing in all kinds of different ways. you helped me out with it. I have no doubt there is a issue with it. where the issue is is still the mystery.

I simply do not know where to go with it. it's a hard nut to crack.

because on one hand if we put it back to the way it was in eg 0.4 there are people that have com server registration issues, installer issues due to elevating privileges to install EG we also have problems with running EG as an administrator and then sending in commands via the CLI. problems with restarting EventGhost internally.

and on the other side we have this problem. and only this problem. albeit it's a nasty problem. but it is only one problem. Time has passed since I originally coded this change. my knowledge of internal Windows workings has grown leaps and bounds. currently it is using pywin32 which does have some glitches in it. I do not know if maybe the glitch is with it and not my code. I tried before to write the named pipe portion without the use of pywin32. BUt i didn't have a compete grasp on the inner workings of ctypes and comtypes. Now I have a much better understanding.


One of the things I also noticed was an issue with the build process. I never knew there was a problem with the build process. But there is. And this is the goofy way this all maps out. and the reason why most likely it would always run without problem for me.

There was a feature that was added to EG a long while back (not something i added). what this feature does is it locates any python installations matching the same version as the one EG runs. if it finds one it adds that installations modules so they can be loaded in EG. this is the trip wire. I found that the builder is not grabbing all of the modules it should be when it is packaging EventGhost. But because I have python installed with all of the proper modules if something is missing from the actual build process I would never even know it. because EG simply grabs the missing bits from my installation of python when i test Eventghost, You guys do not have python installed and there for will not be able to supply any missing bits if there are any. and would get errors when I do not. I just came across this bumble fuck of a problem this past week.
I do not know if this is the possible cause or not. but it is something that very well could be causing it.

I never give up on a problem. Need to step back sometimes and get a bigger picture. I also need time to learn. I am still very much a green horn in terms of programming. It has only been 3 years. 3 years with not one iota of any classes or schooling. I am doing my absolute best that i can. and I am learning as fast as i can. I am also going bald a lot faster because of it. You have to remember too I am not the original author of EG. while I have managed to get a really good understanding of the internal workings I still have not covered everything. I do not know what the original design purpose was. it has made it very difficult to add new features/bugfixes while maintaining the API so plugins still work properly. I am also making sure the code i write is easy to understand to others and to also makes EG become what also of users want to see. things like being able to have EG run without being logged into the computer. making a Linux variant of EG. I accomplished one thing which was making a 64 bit version of EG. So now I know of the goofy things associated with that and how to write code in a manner that will make EG work in either a 32bit or 64 bit OS. so I do not make additional work for myself later on.

We also make use of modules that other people have written. and if a bug is found in that module that causes a problem. I do my best to repair it. I had this exact thing happen with the pywin32 module and the Speech plugin not working properly. I submitted the issue to the author of pywin32. the author just recently added the fix to the core code. I found the problem almost a year and a half ago. funny thing is i submitted the repair and the author coped and pasted the code i wrote and then closed my Pull request to add my code not giving any kind of credit. that kinds pisses me off. and it also shows how well the code is maintained. Bitmonster had started writing a replacement for pywin32 his goal was to steer away from the use of pywin32. I now understand as to why he started doing this. and I have been working on what he started. half a million lines of code and still going.

[Snowbird]

Hi Kevin,

thanks for your detailed reply, I didn't mean to offense you, really ! We all know how hard you work to please us ! you don't need to tell us all that, it's all obvious, you are everywhere and in every topics And I know you have already spent a lot of time to try to fix this NamedPipe issue, that's why I never insisted again, because you did your best at that time. It's just frustrating (at least for me) to see new plugins arriving, new implementations, new ideas, new upgrades of EG, and so on... when in parallel I see some core features that don't work as they should. I know you can't fix everything, for everyone, all the time, and by the way, you don't have to , but it's frustrating.

As for the problem that you are exposing regarding your windows setup and all the python tools associated, I know this may sound stupid, but why don't you create a simple VM, with a basic windows installation so you will be in a neutral position, like many of us, and maybe you will see more quickly some problems that we are reporting ? I'm not trying to teach you anything, I don't know the tenth of your knowledge, I'm just giving you a simple idea in case you didn't already explored it.

And finally, skribb remark may be useful :

I draw the conclusion that these errors are somehow related to processor threads/performance?

I don't know if while running your different tests months ago, you have tried on a slow computer ? maybe that could be it ? it wouldn't hurt to try that as well.

Thanks

[skribb]

Thanks K for your reply.

I was thinking about workarounds.

1. installing the Python version that K is running - would this effectively work around the issue? I don't really mind if I need to have the Python library installed separately from EG.

2. enabling the webserver in EG and making localhost HTTP requests to EG instead of using the -event CLI switch.

3. something quick I tried just now:
make an AHK script that sleeps for 50ms, then kills itself. compile this to an exe. EG's Process Watcher will pick up the process destruction and this can be used to trigger events in EG "from outside". This workaround, of course, is not compatible with the use of payloads. However you could write the payload to a txt file and "receive" the payload in EG using the File Operations plugin, upon detecting the .exe destruction mentioned above.

[kgschlosser]

@Snowbird

I know it is frustrating for you. and it is for me as well. I want EG to run properly for you. All of the features. There is a glitch somewhere. the question is where.. Now if you look in the EventGhost News section of the forum you should see a post about 64bit EG. This version of EG has been compiled using a different mechanism that does a better job at discovering items that should be included with EG. You can give that a shot and see if by chance the issue with the Named Pipe could be due to a missing component possibly.

@skribb
You can use whatever workaround you like to help to solve the issue at the moment. the webserver plugin would be the easiest solution so long as whatever it is that you are trying to generate an event from supports sending an HTTP request.



I am going to start back up with rewriting the named pipe once again. Since my understanding of the Windows API and connectivity between it and Python has gotten a whole lot better maybe i can get it right this time.

I have also toyed around with the idea of kicking the named pipe idea to the curb in favor of using TCP sockets. as this would be the mechanism that would get used when we turn EG into a service. This is something that is not going to take place anytime soon But as i said in my previous post. I want to code for the future and not have to redo. The sockets portion of Python is tried an true so there should not be any kind of a real issue there. I think that is what I am going to do instead of continuing to try to figure out what is with the named pipe. It will not take me that long to make the changes. So Snowbird watch for a message on slack with an experimental build you can give a try.

[Snowbird]

2. enabling the webserver in EG and making localhost HTTP requests to EG instead of using the -event CLI switch.

That's the workaround I've been using for a while now, it works fine, never had an issue with it. The only drawback is that not every program lets you execute an HTTP request, so it may not be used in every case...

[kgschlosser]

Well I am hoping my last bunch of changes work out. @Snowbird is testing them out. we will see if it solves the issue. I have my fingers crossed.

I tried to submit the code to be added to the EG core. GitHib is having some kind of a major data issue. Which the timing is about right. Microsoft did just take them over not to long ago. it was about time some ding dong stuck there finger into something they shouldn't have. they are probably trying to convert all the servers over to Windows and they seeing BSOD's LMAO!!!!!!