Crash when reconnecting often

[BrandonDusseau]

When one or more connections fail and do not work within so many tries, the client crashes.

The cause of and number of attempts required for this is currently unknown. Could not reproduce manually by causing DNS failures or removal of network connection entirely. Will update when more is known.

Expected behavior: client continues or gives up trying to reconnect
Actual behavior: client crashes after reconnection attempts

Version: 2.9.5
Compiled: Apr 1 2013
Portable Mode: No
Build Type: x64
OS: Windows 7
Charset: CP1252

Continued from issue #325 at request of @Arnavion

[RosaryMala]

After doing some testing, it's crashing in line 375 of giowin32.c in glib. Doesn't help much with finding the cause, but it's something.

Still occurs with 2.9.6b3.

Steps to reproduce:

• /set net_auto_reconnectonfail 1
• /set net_reconnect_delay 1
• open a network, join some channels
• set up IRCd on localhost
• connect to localhost
• kill IRCd, let HexChat keep reconnecting
• focus a different tab (? may not be required)

It takes about 10-20 minutes, and the crash occurs. If you run HexChat directly from VS, it points to server.c, but if you attach to a separate instance it points to giowin32.c.

Sometimes it just crashes during runtime, sometimes you have to try to quit HexChat to trigger it.

My (failed) attempt at fixing this: https://gist.github.com/bviktor/5613135

Useful links:

http://stackoverflow.com/questions/5487249/how-write-posix-waitpid-analog-for-windows
http://stackoverflow.com/questions/1087491/postthreadmessage-returns-error-invalid-thread-id
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686360(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms687069(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms687032(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644946(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684335(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686769(v=vs.85).aspx

[BrandonDusseau]

Hexchat does not have to be in the background for it to crash on me. I
think that's a different issue. It takes less than a minute for it to occur
for me, in the foreground. I couldn't get Visual Studio to debug it because
I'm missing a DLL somewhere.

It may be worth mentioning that I'm connecting to my bouncer, so usually
the connection times out on all server tabs at once. That may or may not
have something to do with it.

Also, when it does crash, it's when my wireless bridge fails. If I
purposely disconnect my network, whether before connecting or while
connected, it does not crash. It looks to me like it'll only happen when
the network connection is still active but the IRC server connection times
out.
On May 20, 2013 10:28 AM, "Berke Viktor" notifications@github.com wrote:

Still occurs with 2.9.6b3.

Steps to reproduce:

• /set net_auto_reconnectonfail 1
• /set net_reconnect_delay 1
• open a networks, join some channels
• set up IRCd on localhost
• connect to localhost
• kill IRCd, let HexChat keep reconnecting
• focus a different tab
• leave HexChat in the background/tray

It takes about 10-20 minutes, and the crash occurs. If you run HexChat
directly from VS, it points to server.chttps://github.com/hexchat/hexchat/blob/master/src/common/server.c#L1607,
but if you attach to a separate instance it points to giowin32.chttps://git.gnome.org/browse/glib/tree/glib/giowin32.c?id=2.36.2#n375
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/600#issuecomment-18150157
.

Yeah, background was just a guess, it doesn't matter, I removed it from the post.

It's most likely a threading problem, either in HexChat or in giowin32's read_thread() (since HexChat worked correctly with previous GTK+ stack, I suspect the latter one). The fact that for you it crashes when you have a severe concurrency situation also confirms this.

As for the crash trigger, you're prolly right. It won't crash when there's no connection. You need to have a working link but be unable to reach the server, and have an existing, working connection to something else.

[TingPing]

So I was finally able to repro a crash when connecting, I'm not sure if its the same one but steps to repro:

/server test (must be invalid)
*wait for it to try to connect*
/discon
*it will print "Stopped previous connection attempt" and crash*

VS pointed to server.c#1577.

[tomek]

It seems that loading perl plugin and putting ANY perl addon - or even empty file something.pl in Addons dir "fixes" that bug. Maybe not fixes, Hexchat just don't crash when you try to reproduce it using TingPings method. We still need to find real solution for it

[Arnavion]

<Arnavion> server.c line 568:   g_idle_add ((GSourceFunc)server_close_pipe, pipefd);
<Arnavion> This needs to be delayed more than just scheduling it on idle
<Arnavion> because it happens too fast
<Arnavion> so the process fails to write to the pipe
<Arnavion> For testing, you can comment that line out and you should no longer be able to repro
<Arnavion> but of course then you'll just leak handles, so that's not a shippable fix

The Perl script thing probably affects it because it's a timing issue. If the call to server_close_pipe gets delayed long enough then the child can write to the pipe just fine.

[Arnavion]

<Arnavion> It's impossible to use /DISCON to abort a connection attempt on Windows
<Arnavion> On Linux it spawns a new child process for connecting, and on /DISCON it sends a SIGKILL to that process and waits for it to die
<Arnavion> On Windows it spawns a new thread instead
<Arnavion> and on /DISCON it basically does nothing to the thread
<Arnavion> but queues a callback to close the thread's I/O pipes when the main application loop is idle
<Arnavion> Well, it's not precise to say it does nothing to the thread
<Arnavion> There is a misguided attempt to send a window message WM_QUIT to the thread
<Arnavion> However that function will not work, and in fact it will return an error (which is ignored)
<TingPing> could that crash happen with autoreconnect?
<Arnavion> I don't think so. That crash won't happen with autoreconnect
<Arnavion> It only happens if the connection attempt is stopped outside of its own volition (for example using /DISCON)
<Arnavion> Otherwise the thread just returns an error code that HC interprets to mean "Connection attempt failed"
<TingPing> in that case its not the crash that is commonly reported
<Arnavion> The weird thing is that the bug in question is by someone who says he did experience it with autoreconnect
<Arnavion> I'm thinking tomek's repro is just another bug, not related to the OP

[SineSwiper]

This appears to be fixed in 2.9.6. Ethernet disconnects that would normally crash the client seem to be handled just fine.

Can other folks confirm this?

[Arnavion]

It hasn't been fixed, no. It is a timing issue which means it can still randomly occur.