Opened 9 years ago
Closed 9 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 | |
Platform: | All |
Description
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 by , 9 years ago
comment:2 by , 9 years ago
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 by , 9 years ago
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).
comment:4 by , 9 years ago
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 by , 9 years ago
This sounds similar to #12467, though in the latter case there is no console output indicating abort() was called.
comment:6 by , 9 years ago
Blocking: | 12614 added |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
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 timeOn 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 =)