LAME encoder crashes

[ttcoder]

hrev46188 First thought it was not the PM's fault but rather due to my using an old BeOS binary... But that binary always worked previously, and the build over at haiku-ports crash in the exact same way, downloaded from there: ​http://ports-space.haiku-files.org/media-sound/

Crash first seen in the PM branch, and still there after the merge.

[anevilyak]

Please attach a crash report or at least a backtrace.

[ttcoder]

LAME crashes in some termcap-related code

[scottmc]

I've already written a preliminary .recipe for Lame, but haven't done much testing with it yet. Are there any other packages/libraries that you need in the near future? I'll probably be updating taglib to 1.9.1 in the next few days or so. If you have any packages/library requests for HaikuPorts to get added sooner than later you can open a new issue request at haikuports.org, you'll need get a bitbucket account to open a new issue.

[ttcoder]

Thanks much Scott! Nothing elaborate involved, in order to reproduce the crash, just invoke lame without arguments and it crashes right there; I suppose this is still true for v 3.99, right ?. Which, in addition to my spending time on haiku-files/haikuports this afternoon, led me to file this ticket here as it's probably not a matter of updating the package, it seems to be a regression introduced in Haiku's termcaps or something...

In order to upgrade all our people to 'PM' builds our 3 priorities are lame, lame, and lame ;-) since it is involved in CD ripping (to encode the Wav tracks to mp3) and is involved in streaming (unless one is streaming Ogg or just broadcasting over-the-air). The only other item on the wishlist would be a .hpkg for taglib indeed, currently we're copying the library by hand.

[Giova84]

I can confirm this bug using lame, and i have the same issue with the provided version of ffmpeg: https://dev.haiku-os.org/ticket/10078

[siarzhuk]

Replying to ttcoder:

Which, in addition to my spending time on haiku-files/haikuports this afternoon, led me to file this ticket here as it's probably not a matter of updating the package, it seems to be a regression introduced in Haiku's termcaps or something...

The binary was statically linked with some [unknown] version of ncurses and fails inside of it - note those _nc_ prefixed function calls in your debug report:

0x61a1b790  0x8d68b4    _nc_capcmp + 0x38
0x61a1ccf0  0x8d6fa8    postprocess_termcap + 0x5c8
0x61a1cd40  0x8d6848    _nc_parse_entry + 0x7a8
0x61a1cf80  0x8d31dc    _nc_read_entry_source + 0x110
0x61a1e770  0x8d241c    _nc_read_termcap_entry + 0x270
0x61a1eba0  0x8cef64    grab_entry + 0x54
0x61a1ebe0  0x8cf40f    _nc_setupterm + 0x193
0x61a1ec20  0x8cd891    tgetent + 0x21
0x61a1f460  0x880a69    apply_termcap_settings + 0x3d
0x61a1f4a0  0x880cea    frontend_open_console + 0x5e
0x61a52720  0x880155    main + 0xf5

It tries to read some terminal capability from /etc/termcap and fails on it. The reason of the problem can be the unavailability of termcap database but as far as I see the /etc/termcap is available on pm-haiku so I have no more ideas. So updating the package could be the only reasonable solution.

[ttcoder]

I've filed ticket 26 over at haikuports, thanks scott and siarzhuk. EDIT: I guess this ticket can be closed now (or soon after the one at haikuports)

[ttcoder]

Issue resolved as far as I'm concerned: I'm on my 15th Audio CD encoding, back-to-back, using yesterday's build of LAME, everything works great.

@scottmc: I'm unable to post a comment to HaikuPorts today.. W+ remains stuck on the "spinning wheel" hourglass for minutes at a time without posting my comment.. Posting here instead:

Started a test..I'm on my 15th or so CD encoding, still going strong.

That's with the second ("-2") version of the package, I see the bin/ folder has moved to its place now.

Ticket 26 is done AFAI'mC. Thanks Scott.

[siarzhuk]

Fixed by updating package.

[scottmc]

Can you test out gogo as well, it's in that same location. IIRC back in the BeOS days gogo was much faster than lame, but with todays PC hardware they're probably about the same speed? That is if gogo is even working correctly. Contact me via email at scottmc2 @ gmail

[siarzhuk]

JFYI: I have investigated the similar case with non-PM build of nano. It fails in the same way in ncurses-5.5 code, that was compiled as static lib. The reason of the crash is trying to handle ta@ entries in terminal descriptions. _nc_capcmp receives -1 in the "tab" parameter and fails trying to parse it. ncurses 5.9 introduces additional watchdog for -1 case in the _nc_capcmp.

Note that old build of nano usues only libroot.so - it has its own ncurses-5.5 code compiled in. So something has been changed somewere else - may be tty settings? Any ideas?

I suspect any old package compiled with libncurses.a on non-PM Haiku revisions will be affected this issue.