invalid memory address or nil pointer dereference about godet HOT 7 CLOSED

@erikdubbelboer see if #27 is similar (though the panic happens on websocket disconnect). I made the pull request to fix the panic I'm facing by just avoiding sending the messages on a connection that is about to be closed.

Speaking of using multiple tabs, I also found that their usage is pretty limited (and in my case, I also want better security/isolation between running tasks). DevTools protocol has the notion of Targets and browser contexts which might help here. But in my project I decided to go further and always use a throw-away docker container to run each command. See it here: https://github.com/iafan/hc

from godet.

I'm not using remote.Close so this is a different issue, your pull request will not fix this as in my case remote.isClosing will stay false.

I need to load as many pages as fast as possible so using throw-away containers is waaay too slow. That's why I'm using multiple tabs for lower memory usage and each tab is fetching different pages at the same time. I don't think Targets and browser contexts have anything to do with this, they seem to be for using safe browsing and being able to load pages into different context where they don't share cookies and local storage.

from godet.

I have just added an example of opening multiple tabs in parallel, since it seems to be a hot topic :)
I will check into your panic. Is this on Linux ? (I normally do all my testing on a Mac)

Regarding changing the API to better support of multiple tabs, it's an interesting idea and I have given it a little thought (again, somebody else had a problem with multiple tabs). While it would make the API more clear and easier to use, using multiple RemoteDebuggers is not really that bad and if you look at it, the RemoteDebugger object is pretty much all about managing the connected tab.

Anyway, again, I will give it some more thought. Thanks!

from godet.

Can you update and try again ?

from godet.

I can tell you that doesn't fix a thing without even trying. Here is the real problem:

I call Connect() which calls connectWs() which sets ws and starts readMessages() in a goroutine.
Now before this goroutine has done anything Connect() returns and my code calls NewTab() which in turn calls connectWs() again which starts another readMessages() gorountine.
Now at this point both goroutines actually start and both call socket() which returns the exact same ws (the one that got set with NewTab()). Then they both call ws.ReadMessage() on the exact same ws instance. gorilla/websocket is not designed to be thread safe at all so as you can see this makes things panic immediately.

The fix is to not call socket() in readMessages() but instead get the socket as argument. In this case the first readMessages() goroutine would just try to read from the ws that was closed when I called NewTab().

from godet.

Ok, please try now.

from godet.

Yes that fixes it 👍

from godet.