Fixes#10919.
Removing an interface triggers this sequence:
datalink_control() calls interface->ReleaseReference() which causes the
Interface destructor to be called. The Interface destructor calls
put_device_interface(fDeviceInterface) which destroys the
net_device_interface, then calls put_domain_datalink_protocols(this, datalink->domain)
in a loop. put_domain_datalink_protocols() tries to access the deleted
net_device_interface, hence the KDL.
Change-Id: I2326bcd6d1fd80a69e5fdfa6629563b38ecdbbac
Reviewed-on: https://review.haiku-os.org/469
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* Store pointers in an addr_t instead of int32, for 64-bit's sake
* Use DebugSupport.h instead of userlandfs Debug.h and remove extra parentheses
* Create a header-only String class based on the userlandfs String and use it
* RecursiveLock instead of Locker.
* Jamfile cleanups and other misc. changes.
It isn't yet adapted to the new VFS API, so the build is still somewhat
broken.
An example of the new prompt line format is:
~/Desktop/haiku :) $
Or if the last command exited in failure:
~/Desktop/haiku :( $
The smiley-face will be either dark green or red, also depending on
the command status.
I realize this could be a tad controversial, especially for those used
to the old prompt, but it seems to be a pretty useful feature to me
(and of course kallisti5 came up with it.) But if the bikeshed turns
out to be too large, we can revert it and deal with it after the beta.
As for $ vs > -- BeOS R5 used $, most modern Linux uses $, and having >
come after a space looks much stranger.
These changes were made to etc/profile by PulkoMandy last year, but he missed
making the change in SetupEnvironment. etc/profile calls SetupEnvironment,
so we can consolidate all this there.
Also clean up some syntax.
This contains the contents of Haiku's sources, which is necessary
to include in "with source" builds for proper (L)GPL compliance,
mostly because we have GPL code in the tree.
TeamDebugger:
- When a job is aborted, instead of calling into the user interface directly
to reset the status message, post a message to do so. Also, only post the
message if we aren't already in a terminating state. Otherwise, if jobs
were still running while the team debugger is executing its destructor, it
would attempt to make calls to the already destroyed user interface. This
bug has likely been with us for quite some time, but was hidden by incorrect
ref counting in the past (see #12343).
ExpressionPromptWindow:
- Post a quit requested rather than quitting directly. As a consequence of
this oversight, the team window would never get the notification that the
prompt had been closed, and would consequently not reset its internal state
properly.
It seems the old one was just broken (see mailing list discussion.)
This new one was built from the generic one, but it was done using
a trunk build of Clang 8 with tuned optimization flags, and is
smaller (101 instructions) than GCC 8's (134 instructions) and
the old hand-optimized one (~125 instructions?) as well as being
targeted for ARMv7 instead of ARMv6 like the old one was.
In the future, we may want to look at newlib's ARM memcpy, which
is probably much more hand-optmized than this one is, but this
is at least better than what we had before.
Thanks to mmlr for spotting this. The wrong format specifier was used,
which would lead the server to get the wrong size and do strange things.
Chunked uploads should now work a lot better.
While I was at it, put the line termination in the printf to save a
write to the socket (these are unbuffered and each of them costs us a
syscall, and in some cases this has been found to confuse webservers as
we end up sending super small TCP packets).
Replace 'class' with 'struct', since they are already defined as 'struct'
in PackageInfoAttributeValue.h
Pointed by clang [-Wmismatched-tags]
Change-Id: I094d32c3444fe4299a3afe0872ade296f92debf9
Reviewed-on: https://review.haiku-os.org/471
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Replace strncpy with strlcpy, since destination size equals
maximum number of characters to copy.
Pointed by gcc8 [-Werror=stringop-truncation]
Change-Id: I528a35bd071b1d13f16dcec2e8c2007b5bb072b2
Reviewed-on: https://review.haiku-os.org/473
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Increase array size, since gcc8 x86_64 warns 'sprintf' output
between 2 and 20 bytes into a destination of size 16
[-Werror=format-overflow=].
Change-Id: I641db97d963b64b0c3434cd498f29f4dcb61c373
Reviewed-on: https://review.haiku-os.org/472
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
"cpp" is the system C preprocessor, not the one from our cross-compiler,
and in the case of my system which does not have GCC installed at all,
it doesn't even exist.
With this, Clang-ARM builds successfully create a "haiku-arm.mmc".
I couldn't get it to output, even after blessing it with "rune",
but that may just be my fault...
Since hrev52136 holding Shift while clicking the zoom button will
ignore the Deskbar and resize the window to take whole screen area
(the original behavior).
It'd be nice if the keyboard shortcut for zooming - Ctrl+Alt+Z
recognized an additionally held Shift in the same way.
Add shortcut to window.
Fixes#14365
Change-Id: I919ff2c3e8c41e022f8c675ea631daf18ff41eb3
Reviewed-on: https://review.haiku-os.org/470
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
As Stephan said, some apps ignore the return value of Encode(),
and since _OpenCodecIfNeeded() is called from there, this could
cause wasting of cpu cycles.
Change-Id: I80e1464d8532ebf80c514685ef3a25d98d8142fb
A codec context cannot be reopened, anymore.
Reorganize code accordingly.
Remove usage of the AVFormat context (which was not enabled, anyway) since it's no longer possible to do that.
Use av_frame_free() instead of av_free()
Now that HOST_CC is actually passed in, we need to default
everything to it; otherwise, it's up to the Jambase as to
what CC we are actually using.
Found by trying to build Haiku on a system that has no "cc"
executable, but Jam tried to use it anyway (as all three of CC,
C++, and LINK.)
We do a lot of checks against the CC specified in environment,
but we never pass it into the BuildConfig, so we have no guarantee
that's what Jam's actually using.
Additionally remove HAIKU_BOOT_BOARD while we're at it (nothing uses
it anymore), and reorder the sections in BuildConfig to make a little
more sense.
The former is passed to the compiler when linking using it,
the latter is passed to ld when it is invoked directly.
Also modify ArchitectureRules to not overwrite this setting.
