Re: Preparing for elfutils 0.161 - Dec 12/15 -> Dec 18/19?

Re: Preparing for elfutils 0.161 - Dec 12/15 -> Dec 18/19?

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On Tue, 2014-12-02 at 11:40 +0100, Mark Wielaard wrote:
> It is December already. Which means it has been more than 3 months since
> the last elfutils 0.160 release. We have had lots of bugfixes and some
> new features. So lets see if we are ready for 0.161. My goal is to
> release elfutils 0.161 around Friday 12 December/Monday 15 December.

We did a lot of work in the last two weeks (24 commits). And there are
still some patches pending. Which is my fault. I underestimated the
amount of work to get all the robustify patches in to fix the fuzzer
crashes. I think we are almost there, but would like to stabilize the
code a bit more (and get the last couple of crash fixing patches in) and
then push for a release end of this week.

Cheers,

Mark

Re: Preparing for elfutils 0.161 - Dec 12/15 -> Dec 18/19?

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On Thu, 2014-12-18 at 11:37 +0100, Mark Wielaard wrote:
> I'll do some more testing on various arches today and will push out a
> 0.161 release end of the day (Dutch time - UTC+1) unless something
> horrible shows up.

Not horrible, but there are some testsuite issues on arm. I am
postponing the release till tomorrow to have some time to investigate.

Cheers,

Mark

Re: Preparing for elfutils 0.161 - Dec 12/15 -> Dec 18/19?

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]

On Mon, 2014-12-15 at 10:21 +0100, Mark Wielaard wrote:
> On Tue, 2014-12-02 at 11:40 +0100, Mark Wielaard wrote:
> > It is December already. Which means it has been more than 3 months since
> > the last elfutils 0.160 release. We have had lots of bugfixes and some
> > new features. So lets see if we are ready for 0.161. My goal is to
> > release elfutils 0.161 around Friday 12 December/Monday 15 December.
> 
> We did a lot of work in the last two weeks (24 commits). And there are
> still some patches pending. Which is my fault. I underestimated the
> amount of work to get all the robustify patches in to fix the fuzzer
> crashes. I think we are almost there, but would like to stabilize the
> code a bit more (and get the last couple of crash fixing patches in) and
> then push for a release end of this week.

I just pushed my remaining mjw/pending robustness patches to master.
These all should be trivial, mostly simple one-liner sanity checks (see
below for the list). I have tested with most of these this week (and
some were the result of that testing against the afl-fuzzer).

I'll do some more testing on various arches today and will push out a
0.161 release end of the day (Dutch time - UTC+1) unless something
horrible shows up.

And then we can start our work for 0.162!
Lets try to release that in March 2015.

Cheers,

Mark

  libelf: Clear any garbage left in the ar name table.
  readelf: Check there is enough room for the DW_LNE_set_address
    argument
  readelf: Make sure there is enough room for reading .debug_line
    unit_length.
  libdw: Add bounds checking to dwarf_getpubnames.
  readelf: Add more bounds checks to print_gdb_index_section.
  libdw: dwarf_getpubnames set error to DWARF_E_NO_ENTRY for zero
    entries.
  readelf: Don't assert when addr_size or ref_size is not 4 or 8 in
    print_ops.
  readelf: Warn, don't assert, if loclist or rangelist offset is too
    big.
  readelf,libdw: Correct .debug_line overflow check for unit_length.
  readelf: Correct overflow check for length in
    print_debug_aranges_section.
  libdw: Make sure there is enough space to read offset in
    dwarf_getpubnames.
  libelf: Check index_size doesn't overflow in elf_getarsym.
  libelf: Make sure ar archive long_names len fits in mapped ELF file.
  readelf: Print dwarf_errmsg if dwarf_onesrcline or dwarf_linesrc
    fails.
  libdw: Check diridx is valid under DW_LNE_define_file in
    dwarf_getsrclines.
  readelf: Add bounds check before each CFA op that takes an argument.
  libdwfl: Make sure symstrdata->d_buf != NULL in relocate
    resolve_symbol.