similar to: minor IA64 ''brown paper bag'' event (createrepo missing

Update: I added my debugging stuff (just a bunch of Print()s and dprintf()s) to the branch without the multinic fix to see if I could find a common cause somewhere. This is based on commit 8702009f. Where I expected the machine to crash again, it just exited back to the bootloader without crashing. So.. somehow adding this debug code solved the crashing problem? Or did it? Then I went back

> I probably messed up in copying over libutil.c32 and libcom32.c32 along with > the various versions of syslinux.efi. On the other hand, there is no lib*.c32 involved in the case where it would not start to load ldlinux.e64 due to the multinic issue. So... How is it possible that a simple recompile with some debugging turned on, resolved the crashing issue. Unfortunately I can't test

>>> So.. my conclusion for now: 8702009 crashed because of some http pathprefix bug 8702009 contains the multinic bug so wouldn't work anyway e466d24 solves the mutlinic bug AND the http pathprefix bug e466d24 kept crashing on me because I mixed up libraries from 8702009 e466d24 still has an issue with png's in vesalinux causing crashes <<< This is a good

On 07-08-15 18:29, Patrick Masotta wrote: >>>> > So.. my conclusion for now: > > 8702009 crashed because of some http pathprefix bug > 8702009 contains the multinic bug so wouldn't work anyway > e466d24 solves the mutlinic bug AND the http pathprefix bug > e466d24 kept crashing on me because I mixed up libraries from 8702009 > e466d24 still has

>>> On 07-08-15 16:03, Oscar Roozen wrote: e466d24 still has an issue with png's in vesalinux causing crashes I can confirm this remaining crash is caused by the line "MENU BACKGROUND bootlogo.png". <<< Since last week I've been able to reproduce this problem. This is a weird bug affecting zlib but it looks like a compiler issue (v4.7.2) Please

On 11-08-15 10:07, Patrick Masotta wrote: > Please implement these new changes over your last non-debug > working build (multi-nic fix) and let's see how it goes. > > https://github.com/ppatpat/syslinux/compare/master...ppatpat:zlib?expand=1 > > Please report your results. Results are in. They are very good. No crashing even with the original config!

> > For me this has a very low priority, as the jpg workaround is just fine. Well, vesamenu.c32 under UEFI, although "almost needed", it is already behaving in a crappy manner anyway :(. (Reminder, FWIW, PNG is non-patented, loss-less and popular.) With so many regressions and features not working (in vesamenu under UEFI), I have "suggested" in past months /

>>> > Please implement these new changes over your last non-debug > working build (multi-nic fix) and let's see how it goes. > > https://github.com/ppatpat/syslinux/compare/master...ppatpat:zlib?expand=1 > > Please report your results. Results are in. They are very good. No crashing even with the original config! <<< It is also working here; I

>>> > It is also working here; I think this particular PNG issue is fixed. > > It's worth to mention that the replaced code looks valid to me; that's why I think > this is probably some sort of compiler bug. It was really hard to find. > We should keep an eye on this issue; it might appear somewhere else. Eww.? The original code was merely an empty define.?

>>> > > The empty define should work; actually it did work for many years... > > Your just proposed change was my first attempt for solving this but for some > reason it did not work. After testing a lot the only way I've found to solve this > bug was defining a "real" empty function. I know, 100% hacky but it works. If the voiding doesn't

>>> Patrick, Oscar, what specific build tools are you two using? GNU ld (GNU Binutils for Debian) 2.22 gcc version 4.7.2 (Debian 4.7.2-5) NASM version 2.10.01 Trying to recall if there's other utility packages. -- -Gene <<< I think we run the same building environment... #cat /etc/debian_version Debian 7.8 (64 bits) #ld -v GNU ld (GNU Binutils for Debian)

On Sun, Sep 13, 2015 at 4:38 PM, Patrick Masotta <masottaus at yahoo.com> wrote: >>>> > > Patrick, Oscar, what specific build tools are you two using? > > GNU ld (GNU Binutils for Debian) 2.22 > gcc version 4.7.2 (Debian 4.7.2-5) > NASM version 2.10.01 > > Trying to recall if there's other utility packages. > > -- > -Gene >

>>> > > #cat /etc/debian_version > Debian 7.8 (64bits) My build VM is 32-bit. -- -Gene <<< That could probably mask the problem in your case... Best, Patrick

On 2015-09-13 18:00, Gene Cumm via Syslinux wrote: > Patrick, Oscar, what specific build tools are you two using? Oscar is on holiday for another week. But I'm pretty sure his environment should be: # cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.0 (Maipo) # ld -v GNU ld version 2.23.52.0.1-16.el7 20130226 # gcc -v Using built-in specs. COLLECT_GCC=gcc

On Mon, Sep 14, 2015 at 05:22:40AM -0700, Patrick Masotta via Syslinux wrote: > Teun wrote: } } Gene wrote } } } Smells like an optimizer/stripper bug :( } } } Patrick, Oscar what build environment do you use? > > Oscar is on holiday for another week. But I'm pretty sure his > > environment should be: > > ... } } # gcc -v } } Using built-in specs. } } COLLECT_GCC=gcc }

On Tue, Aug 11, 2015 at 9:11 AM, Patrick Masotta via Syslinux <syslinux at zytor.com> wrote: > >>> > > > Please implement these new changes over your last non-debug > > working build (multi-nic fix) and let's see how it goes. > > > > https://github.com/ppatpat/syslinux/compare/master...ppatpat:zlib?expand=1 > > > > Please report

On Sun, Sep 13, 2015 at 9:22 AM, Patrick Masotta <masottaus at yahoo.com> wrote: > >>>> > > It is also working here; I think this particular PNG issue is fixed. > > > > It's worth to mention that the replaced code looks valid to me; that's why I think > > this is probably some sort of compiler bug. It was really hard to find. > > We

>> Unfortunately I can't test anymore until Friday. Maybe gnu-efi got >> updated? I seem to remember seeing a shell script pulling in the >> newest version during compilation... > > It's version locked to a certain commit ID. Okay, so that's good. No worries there. === preamble === In this mail I talk about two different commits. To identify them furhter,

>>> Oscar is on holiday for another week. But I'm pretty sure his environment should be: ... <<< (Sorry this was in my spam folder...) Well it seems Oscar is building on a 64 bit platform... Best Patrick

Updating myself again: On 07-08-15 16:03, Oscar Roozen wrote: > e466d24 still has an issue with png's in vesalinux causing crashes I can confirm this remaining crash is caused by the line "MENU BACKGROUND bootlogo.png". The original bootlogo.png is 640x480. Forcing the videomode with "MENU RESOLUTION 640 480" did not resolve the crashes, nor did resizing the png