Web+ window just closes

[humdinger]

This is hrev49856.

I had maybe 8 tabs open in Web+, and was opening new and closing other tabs for an hour or so. Then, while entering some text in crappy Google-GCI task form, Web+ simply closed the window. This was all that could be found in the syslog:

KERN: intel_extreme accelerant:CALLED status_t intel_get_edid_info(void *, long unsigned int, uint32 *)
KERN: 1336: DEBUGGER: Could not create BWindow's receive port, used for interacting with the app_server!
KERN: _user_debugger(): Failed to install debugger. Message is: `Could not create BWindow's receive port, used for interacting with the app_server!'
KERN: thread_hit_debug_event(): Failed to create debug port: No more ports available

[ttcoder]

DEBUGGER: Could not create BWindow's receive port

IIRC we've seen this before, when the system is running out of ports (as evidenced by sysinfo -ports continuously running in a background terminal). Back then it was due to a leak but that's been since fixed. So it could be 'genuine' port usage this time

On a side note I also noticed a different problem (BHttpRequest apparently throws a signal or an exception in some circumstances) but probably affects only myself so will wait until the skies clear up before bringing that up =)

[pulkomandy]

Yes, this looks like running out of ports (it would be nice to know which page still causes this, because we have reduced the use of ports a lot with Jua's work).

And yes, the service kit does use the SIGUSR1 signal to unblock a thread stuck on a read() or write() when the connection is closed. This could be removed, if closing the socket did unblock read and write operations, but in Haiku (and Linux) it currently doesn't.

[ttcoder]

Finally found the "use case" while reviewing my notes; likely not relevant, but let's confirm:

/boot/system/cache/tmp/New folder> cat quit_on_httpreq.cpp 

#include <net/Url.h>
#include <net/HttpRequest.h>

int main()
{
        {
                BHttpRequest httpReq("https://dev.haiku-os.org/ticket/12497");
                httpReq.Run();
                
                snooze(100);
        }
        
        puts("still here (no uncaught exception or signal)");
        
        return 0;
}
/boot/system/cache/tmp/New folder> ./quit_on_httpreq 
still here (no uncaught exception or signal)

if I change the snooze to snooze(10) or even remove it, I mostly get this:

/boot/system/cache/tmp/New folder> ./quit_on_httpreq 
User defined signal 1

I take it, this is not something that what Web+ is likely to ever suffer from ? Might need to be put in a prominent position in the documentation (if not already so) in case it surprises anyone writing such a code flow (req deleted just after being created), though such a flow appears unlikely. An interesting question would be, does the "user defined signal" stdout/stderr message ever fail to appear (as it had in my case when I initialy stumbled on this last year IIRC).

[pulkomandy]

The use of "user defined signal 1" is there as a workaround, because of threading issues with Haiku's socket code. The problem is as follows:

• running the http request spawns a new thread, where the socket operations are done
• when deleting the request, its socket is shutdown(), then close()'d
• this is supposed to unblock the thread, if it was inside a write() or read(), but, in Haiku, it doesn't unlock if the thread was stuck in connect() (maybe the server is busy and does not accept a new connection).
• to make sure the thread terminates, the signal is used to interrupt the read/write system calls.

The signal is currently configured from inside the thread, which means there is a race condition if the request is deleted before the thread has run far enough.

It is a bad idea to use the signal in this way anyway, and a better solution would be to actually fix connect() to unblock if the socket is closed.

I don't know if that is related to the reported crash, however. Running Web+ in Debugger, with a breakpoint in abort(), would help, if the problem is still reproductible.

[anevilyak]

This sounds similar to #12467, though in the latter case there is no console output indicating abort() was called.