f9ac1e93fb didn't take
into account that the superblock gets written back
from places other than Initialize(), resulting in
unbootable volumes.
Now the first sector will only be erased if the volume
is being initialized.
* When writing the superblock, because it's at sector 1,
sector 0 doesn't get erased. As a result, if an
existing file system was present, identifying details
in sector 0 could cause the partition identifying code
to detect an old file system instead.
Fixes#11136.
- When saving our view state, only save a new set of values if a stack
frame clear is pending. Otherwise, check if there is a previously
existing view state, and take over its values. This ensures that we
correctly remember our previous values when the user is simply switching
stack frames while in a stopped state.
I have at least one CD which does that. There is no problem in handling
it since CP-1252 is a superset of ISO-8859-15.
Also fix the possible buffer overflow in the CD-Text handling, which
could corrupt the stack in case a track title decodes to more than 256
bytes. Now it is properly truncated on a character boundary.
Put more information on a single line. This makes it easier to keep
track of things when debugging higher level parts of the disk stack
(partitionning and file systems).
* When opening documents without be:caret_position,
StyledEdit would place the cursor at the end of
the file. _LoadAttrs() intended to set it to the
beginning; however, a check for an existing BRect
for positioning the window would return early,
preventing the caret position to be set.
Fixes#11463
- Pass address size to DwarfManager, and subsequently DwarfFile's Load()
method, as that information is needed in order to parse the frame
information correctly early on.
- When initially loading debug information, also do a quick pass through
.{debug,eh}_frame, and build a lookup table of offsets. This is then
used later when actual unwinding is requested in order to quickly find
the corresponding FDE/CIE. Should noticeably improve performance when
stepping through code, especially for larger/more complex executable images.
Implements #8613.
In newer versions of udis86, the ud_t.mnemonic field is deprecated,
and one must now call ud_insn_mnemonic() to retrieve that information.
This was causing Debugger to not correctly identify subroutine calls
and jump instructions, which broke the stepping code in various fun
ways.
* curl: security update for CVE-2014-3707
* libpng16 can be installed next to libpng, libpng16_devel cannot be
installed next to libpng_devel (only one of them).
If the requested read was more than 32 frames, and reading them all at
once failed, we would try to read by chunk of 8 frames. But if the
original frame count was not a multiple of 8 we would not adjust the
count for the last read.
Unfortunately I could still panic the system after fixing this, so it is
not *the* cdda bug.
The new udis makes it possible to hook a symbol lookup function, so we
can get symbol names and offsets instead of raw addresses in call and
jump instrucitons.
In two cases:
* Out of memory and strdup on fName failed. Nothing would be
initialized (mostly harmless: InitCheck would detect this)
* There are no frames in the track: the wav header would be left
uninitialized, and this would be readable from userland (bad thing, but
needs a specifically crafted malicious CD to happen).
I had a KDL when trying to read an audio CD which apparently uses this
as a copy protection scheme.
I don't know if this is the right place to do this, the KDL would happen
further down when the intel partitionning system or bfs would try to
read data from the disk at offset -2048.
This looks better and is what we want here. The difference is subtle,
just a few pixels on the left and right side of the tabview where it now
properly joins the window border.
* As 104Mhz is stores as 10400 on atombios,
and 104000 everywhere else... this conversion
was going the wrong direction.
* Shrink the stored value to 10Khz units to properly
compare to the AtomBIOS value
