Opened 3 years ago

Closed 3 years ago

#12497 closed bug (duplicate)

Web+ window just closes

Reported by: humdinger Owned by: pulkomandy
Priority: normal Milestone: Unscheduled
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #12614
Has a Patch: no Platform: All


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

Change History (6)

comment:1 Changed 3 years ago by 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 =)

comment:2 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by 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("");
        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).

comment:4 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by anevilyak

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

comment:6 Changed 3 years ago by pulkomandy

Blocking: 12614 added
Resolution: duplicate
Status: newclosed
Note: See TracTickets for help on using tickets.