Jump to content

Latest EOF releases (9-26-2020)


Recommended Posts

  • Replies 2.7k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Hi, folks. I'll be using this thread to maintain the latest versions of EOF in one place. To start, download and extract EOF 1.8RC12: http://www.mediafire.com/file/ih70h6p67iy77ka/eof1.8RC12.zip You

Hi, folks. The latest hotfix (r1378) is in the first post. Changes are as follows: *Improved GP import to process bend status for grace notes, it will apply a bend strength to the grace note correspo

Hi, folks. The latest hotfix (r1363) is in the first post. Changes are as follows: *Added a warning during save if any lyrics have extended ASCII or Unicode characters, as these aren't compatible wit

Wonderful, it works great now! Thanks for the support. Also just so you know the "Building EOF in linux" on the wiki is pretty out-dated with a broken link to the Allegro code and at some point the name of the make file changed from "makefile.linux" to "Makefile" so the user has to know to change that in order for the build to work.

Link to post
Share on other sites

  • 2 weeks later...

Keep in mind that MIDI import is meant to import a rhythm game MIDI, not a generic MIDI file, although you can import the time signatures and tempo changes.  You're going to want to import a Guitar Pro file instead in order to bring the tablature into EOF.  That error is not a problem with MIDI import specifically, but a problem with where EOF is installed or third party software interfering with EOF (ie. antivirus or cloud syncing programs).

Link to post
Share on other sites

Is anyone else getting a memory overflow warning when they compile on Linux?

 

In function ‘eof_load_chord_shape_definitions’,
   inlined from ‘eof_initialize’ at main.c:3984:2:
rs.c:4793:7: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=]
4793 |       strncpy(eof_chord_shape[num_eof_chord_shapes].name, name, strlen(name) + 1);
     |       ^
main.c: In function ‘eof_initialize’:
rs.c:4793:65: note: length computed here
4793 |       strncpy(eof_chord_shape[num_eof_chord_shapes].name, name, strlen(name) + 1);
     |                                                                 ^
menu/track.c: In function ‘eof_rebuild_tuning_strings’:
menu/track.c:495:6: warning: ‘strncpy’ writing 7 bytes into a region of size 5 overflows the destination [-Wstringop-overflow=]
 495 |      strncpy(tuning_list[ctr], eof_note_names[tuning], sizeof(tuning_list[0]) - 1);
     |      ^
menu/track.c:495:6: warning: ‘strncpy’ writing 7 bytes into a region of size 5 overflows the destination [-Wstringop-overflow=]
menu/track.c:495:6: warning: ‘strncpy’ writing 7 bytes into a region of size 5 overflows the destination [-Wstringop-overflow=]
menu/track.c:495:6: warning: ‘strncpy’ writing 7 bytes into a region of size 5 overflows the destination [-Wstringop-overflow=]
menu/track.c:495:6: warning: ‘strncpy’ writing 7 bytes into a region of size 5 overflows the destination [-Wstringop-overflow=]
menu/track.c:495:6: warning: ‘strncpy’ writing 7 bytes into a region of size 5 overflows the destination [-Wstringop-overflow=]
[erik@LINUX src]$ cd ../bin
[erik@LINUX bin]$ ./eof
Segmentation fault (core dumped)

Link to post
Share on other sites

That first warning is technically true in terms of code style, but it's ultimately a false positive since the destination buffer (eof_chord_shape[num_eof_chord_shapes].name) is in fact allocated to store strlen(name) + 1 bytes nine lines of code earlier.  I'll adjust that line to better reflect this and sooth the compiler's warning.

 

The second series of warnings about strncpy seem like they're all false positives.  Almost like the compiler doesn't know what strncpy() really is, since it guarantees no overflow when the last parameter specifies a size that isn't larger than the first parameter's buffer size.  And the string being copied into the destination buffer is never larger than 2 characters while the destination buffer can accommodate 5 characters.

 

So those compiler warnings are not relevant, but it's weird that a segfault is happening.  I've been sticking to an older version of MinGW since at some point the gcc compiler had a drastic optimization change where it could remove NULL pointer checks depending on code style.  You might try adding the -fno-delete-null-pointer-checks compiler flag to see if that helps.  Otherwise I haven't tested this in Linux in a while but the last time I did in Ubuntu it did not crash on launch.

 

Also, the line numbers cited in the warnings seem wildly different from the line numbers in the current version of the source code.  Are you building off the latest git version of it?

Link to post
Share on other sites

This is what I get when using the newest code:

 

gcc -v:

Using built-in specs.

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-pkgversion='Arch Linux 9.2.1+20200130-2' --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.1 20200130 (Arch Linux 9.2.1+20200130-2)
 
gcc menu/file.o menu/edit.o menu/song.o menu/note.o menu/beat.o menu/help.o menu/main.o menu/context.o menu/track.o modules/ocd3d.o modules/wfsel.o modules/gametime.o modules/g-idle.o dialog/main.o dialog/proc.o main.o player.o config.o window.o dialog.o legacy.o midi.o ini.o song.o note.o beat.o event.o undo.o mix.o control.o editor.o utility.o chart_import.o midi_import.o ini_import.o waveform.o silence.o tuning.o gp_import.o midi_data_import.o gh_import.o rs.o rs_import.o spectrogram.o notefunc.o minibpm-1.0/src/MiniBpm.o minibpm-1.0/src/minibpm-c.o bpm.o bf.o bf_import.o notes.o pathing.o agup/aalg.o agup/aase.o agup/abeos.o  agup/abitmap.o  agup/agtk.o  agup/agup.o  agup/ans.o  agup/aphoton.o  agup/awin95.o alogg/src/alogg.o foflc/LRC_parse.o foflc/Lyric_storage.o foflc/Midi_parse.o foflc/Script_parse.o foflc/UStar_parse.o foflc/VL_parse.o foflc/ID3_parse.o foflc/SRT_parse.o foflc/XML_parse.o foflc/JB_parse.o foflc/RS_parse.o lc_import.o -Wall -O2 -fno-delete-null-pointer-checks -fomit-frame-pointer -ffast-math -funroll-loops -flto -Ialogg/include -DEOF_BUILD `allegro-config --libs` -logg -lvorbisfile -lm -lfftw3 -lrubberband -lstdc++ -o ../bin/eof
foflc/Lyric_storage.c: In function ‘Append’:
foflc/Lyric_storage.c:590:9: warning: ‘strncat’ specified bound depends on the length of the source argument [-Wstringop-overflow=]
  590 |  return(strncat(temp,src2,size2)); //Concatenate src1 and src2 and return the resulting string, preventing overflow
      |         ^
foflc/Lyric_storage.c:586:8: note: length computed here
  586 |  size2=strlen(src2);
      |        ^
In function ‘eof_load_chord_shape_definitions’,
    inlined from ‘eof_initialize’ at main.c:4376:2:
rs.c:5183:8: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=]
 5183 |        strncpy(eof_chord_shape[num_eof_chord_shapes].name, name, length + 1);
      |        ^
main.c: In function ‘eof_initialize’:
rs.c:5173:16: note: length computed here
 5173 |       length = strlen(name);
      |                ^
menu/track.c: In function ‘eof_rebuild_tuning_strings’:
menu/track.c:715:6: warning: ‘strncpy’ writing 7 bytes into a region of size 5 overflows the destination [-Wstringop-overflow=]
  715 |      strncpy(tuning_list[ctr], eof_note_names[tuning], sizeof(tuning_list[0]) - 1);
      |      ^
menu/track.c:715:6: warning: ‘strncpy’ writing 7 bytes into a region of size 5 overflows the destination [-Wstringop-overflow=]
menu/track.c:715:6: warning: ‘strncpy’ writing 7 bytes into a region of size 5 overflows the destination [-Wstringop-overflow=]
menu/track.c:715:6: warning: ‘strncpy’ writing 7 bytes into a region of size 5 overflows the destination [-Wstringop-overflow=]
menu/track.c:715:6: warning: ‘strncpy’ writing 7 bytes into a region of size 5 overflows the destination [-Wstringop-overflow=]
menu/track.c:715:6: warning: ‘strncpy’ writing 7 bytes into a region of size 5 overflows the destination [-Wstringop-overflow=]
[erik@LINUX src]$ ../bin
bash: ../bin: Is a directory
[erik@LINUX src]$ cd ../bin
[erik@LINUX bin]$ ./eof
Segmentation fault (core dumped)
 
clang -v
clang version 9.0.1 
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/9.2.1
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.1
Found candidate GCC installation: /usr/lib64/gcc/x86_64-pc-linux-gnu/9.2.1
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.2.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
 
clang menu/file.o menu/edit.o menu/song.o menu/note.o menu/beat.o menu/help.o menu/main.o menu/context.o menu/track.o modules/ocd3d.o modules/wfsel.o modules/gametime.o modules/g-idle.o dialog/main.o dialog/proc.o main.o player.o config.o window.o dialog.o legacy.o midi.o ini.o song.o note.o beat.o event.o undo.o mix.o control.o editor.o utility.o chart_import.o midi_import.o ini_import.o waveform.o silence.o tuning.o gp_import.o midi_data_import.o gh_import.o rs.o rs_import.o spectrogram.o notefunc.o minibpm-1.0/src/MiniBpm.o minibpm-1.0/src/minibpm-c.o bpm.o bf.o bf_import.o notes.o pathing.o agup/aalg.o agup/aase.o agup/abeos.o  agup/abitmap.o  agup/agtk.o  agup/agup.o  agup/ans.o  agup/aphoton.o  agup/awin95.o alogg/src/alogg.o foflc/LRC_parse.o foflc/Lyric_storage.o foflc/Midi_parse.o foflc/Script_parse.o foflc/UStar_parse.o foflc/VL_parse.o foflc/ID3_parse.o foflc/SRT_parse.o foflc/XML_parse.o foflc/JB_parse.o foflc/RS_parse.o lc_import.o -Wall -O2 -fomit-frame-pointer -ffast-math -funroll-loops -flto -Ialogg/include -DEOF_BUILD `allegro-config --libs` -logg -lvorbisfile -lm -lfftw3 -lrubberband -lstdc++ -o ../bin/eof
ld: error: /usr/lib/libfftw3.so: undefined reference to __log_finite
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [makefile.linux:14: ../bin/eof] Error 1
Link to post
Share on other sites

I'm still guessing it's a GCC issue with it behaving differently than on other platforms.  That compiler warning in Append() looks like another false positive.  It might not be understanding my malloc_err() wrapper function that guarantees the string is large enough to append the two input strings together.  I guess you could check eof_log.txt and see how far it gets.  You could also open eof.cfg when EOF isn't running and change the eof_log_level value to 2 or 3 to increase the amount of logging performed and possibly better identify how far the program gets before entering the normal loop waiting for user input.

Link to post
Share on other sites

This is what I get when I run gdb:

 

[erik@LINUX src]$ gdb ../bin/eof
GNU gdb (GDB) 9.1
Copyright © 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
 
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../bin/eof...
(gdb) r
Starting program: /editor-on-fire-master/bin/eof 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
 
Program received signal SIGSEGV, Segmentation fault.
0x000055555566c4cf in set_window_title (name=<optimized out>, name=<optimized out>) at /usr/include/allegro/inline/system.inl:29
29      AL_INLINE(void, set_window_title, (AL_CONST char *name),
(gdb)
Link to post
Share on other sites

This is what I get when I run lldb:

 

[root@LINUX src]# lldb ../bin/eof             
(lldb) target create "../bin/eof"
Current executable set to '../bin/eof' (x86_64).
(lldb) r
Process 31535 launched: '/usr/src/editor-on-fire-master/bin/eof' (x86_64)
Process 31535 stopped
* thread #1, name = 'eof', stop reason = signal SIGSEGV: invalid address (fault address: 0x40)
    frame #0: 0x0000555555618530 eof`eof_initialize [inlined] set_window_title(name=<unavailable>) at system.inl:29:1
   26   #endif
   27  
   28  
-> 29   AL_INLINE(void, set_window_title, (AL_CONST char *name),
   30   {
   31      ASSERT(system_driver);
   32  
(lldb)
Link to post
Share on other sites

This is what I get when I compile with MemorySanitizer:

 

[erik@LINUX src]$ ../bin/eof
MemorySanitizer:DEADLYSIGNAL
==3210==ERROR: MemorySanitizer: SEGV on unknown address 0x000000000040 (pc 0x55891590f2c0 bp 0x7ffe482b0910 sp 0x7ffe482aff00 T3210)
==3210==The signal is caused by a READ memory access.
==3210==Hint: address points to the zero page.
    #0 0x55891590f2bf  (/home/erik/Build/editor-on-fire/bin/eof+0x1e32bf)
    #1 0x55891591b261  (/home/erik/Build/editor-on-fire/bin/eof+0x1ef261)
    #2 0x7f02be777022  (/usr/lib/libc.so.6+0x27022)
    #3 0x558915769edd  (/home/erik/Build/editor-on-fire/bin/eof+0x3dedd)
 
MemorySanitizer can not provide additional info.
SUMMARY: MemorySanitizer: SEGV (/home/erik/Build/editor-on-fire/bin/eof+0x1e32bf) 
==3210==ABORTING
Link to post
Share on other sites

@@Mricco89 EOF can't open GPX files, you'll need to have Guitar Pro export them as GP5 files.  If you don't have the Guitar Pro program, you can use the free Tux Guitar program (http://www.tuxguitar.com.ar/) to do so.

 

@@Kicker0429 If it's crashing in one of Allegro's functions, there's nothing I can directly do about it.  EOF is only calling set_window_title() with constant strings or with arrays with properly-formed C strings.  It cannot be getting called with a NULL pointer or anything like that.  You might try changing the makefile to build without optimization and see if that gets rid of the problem, then we can work from there.

Link to post
Share on other sites

By any chance would you have enough time to kill to try to debug where the crash is occurring (ie. set a breakpoint within set_window_title() and step through until the system driver eventually gets called?

 

This would probably involve re-building with the -ggdb option so GDB can work fully when debugging it.

Link to post
Share on other sites

After troubleshooting this in the Allegro IRC channel for a while, it seems this is a problem with how Allegro is defined in Arch Linux's package manager or something like that.  I was told that you can install asp, then do "asp checkout allegro4", then do "makepkg -si" to properly build Allegro 4 and then it should work better when you build EOF.  Ie. these steps:

 

sudo pacman -S asp; asp checkout allegro4; cd allegro4/repos/community-x86_64/; makepkg -si

Link to post
Share on other sites

Generally, EOF selects whichever the "default" MIDI device is in the OS, but I don't know how that would be defined in *nux.  From some Googling it sounds like a limitation with Allegro and the distro's sound system.  The top post at https://bugs.launchpad.net/ubuntu/+source/overgod/+bug/311833 suggests you may be able to just define a symlink so midiC0D0 points to your correct sound device name.  May be worth a try.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.


×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. - Privacy Policy