Latest Bugs & Tasks

Present in R1A4, and hrev45686 gcc2h(although output differs slightly)

Steps to reproduce:

• Open Paladin
• Create a new project using template GUI with Main Window
• Make the project (just with defaults)
• Open Terminal and issue command "settype -s Application/x-vnd.test BeApp" (BeApp is the recently compiled executable)
• call BeApp using Terminal (using Tracker also works)
• Crash! a debugger appears as if it were KDL but instead is GNU GDB

At this point you can write "continue" to return to Desktop, and you will find yourself unable to open any executable.

• All of them say BAD PORT ID error
• Somewhere says registrar was killed
• Other weird thing happens: you cannot shutdown/reboot using the deskbar neither commandline, desktop items aren't refreshes (i.e. copying/creating new files there) and so...

This undoubtedly has bothered nobody but me, but it is a trivial fix, and probably should be applied. It has always been incorrect in fluidsynth, and still is in the latest source of theirs. I've notified their mailing-list, so hopefully it will get applied before we next update our copy.

The GM MIDI standard (​http://www.midi.org/techspecs/midimessages.php#3a) says that the range should be +/- one semitone (+/-100 cents) but it was only +/-50 cents in fluidsynth. As I quite often need to adjust both piano and synth to match an off-tune recording, this caused great ugliness...

A (2 line) patch is attached.

I noticed there is no sniffer rule for MP3 files, which causes a problem when those files do not have an extension.
I checked a bit on the internet and I think the rule should be (to be added to src/data/beos_mime/audio/mpeg):

resource(6, "META:SNIFF_RULE") "0.50 (0xfffb|0xfffa|\"ID3\")";

I only have mp3 which conform to the first option (oxfffb), so I cannot test the other two options.

I'm not quite sure under which component this should go. Please change if it is not the right one.

Patch applied in hrev45710. Thanks.

And thanks everybody for *not* having underlined why I've succeeded to screw the first apply attempt ;-).

Hello. I am wondering if there have been any changes to BDirectWindow code from Alpha 4.1 to the current hrevs. I have code that works fine in A4.1 but crashes nearly immediately in hrev45704. It's been difficult for me to track down the problem because the graphical debugger does not provide any source path. The best I can do is provide information from MALLOC_DEBUG, hopefully it will be of help to someone.

KERN: vm_soft_fault: va 0x152000 not covered by area in address space
KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x152c00, ip 0x455acf, write 0, user 1, thread 0xa507
KERN: vm_page_fault: thread "pretendo_thread" (42247) in team "pretendo" (42237) tried to read address 0x152c00, ip 0x455acf ("pretendo_seg0ro" +0x82acf)
KERN: debug_server: Thread 42247 entered the debugger: Segment violation
KERN: stack trace, current PC 0x455acf (/pretendo/pretendo/pretendo + 0):
KERN: (0x729414e0) 0x450b07 _ZN14PretendoWindow10DrawDirectEv + 0x107
KERN: (0x72941550) 0x450ce8 _ZN14PretendoWindow10BlitScreenEv + 0x78
KERN: (0x729415b0) 0x450e20 _ZN14PretendoWindow9end_frameEv + 0x30
KERN: (0x729415d0) 0x45103e _ZN14PretendoWindow16emulation_threadEPv + 0x3e
KERN: (0x72941600) 0x16702e7 thread_entry + 0x1c
USER: application/x-vnd.scanty-Pretendo killed for a problem in DirectConnected(): Operation timed out
KERN: debug_server: Killing team 42237 (./pretendo)
KERN: debug_server: TeamDebugHandler::Init(): Failed to get info for team 42237: Operation on invalid team
KERN: debug_server: KillTeam(): Error getting info for team 42237: Operation on invalid team
KERN: debug_server: Killing team 42237 ()

I'm not sure why the code works fine in A4.1, but fails in later revisions. Maybe someone can shed some light on this issue. Thank you.

4.7.3 integrated in btrev43056. GCC with graphite fixed in btrev43057. ppc and m68k builds fixed in btrev43058.

Is not more reproducible. Checked on hrev45705.

I have checked behaviour of BS on Konsole, XFCE Terminal and xterm and found no differences with current behaviour of Haiku Terminal. No erase is performed. So, no changes required. Mentioned visual issues in the Midnight Commander 4.8.8 are the problem of that 3rd party application but not Haiku Terminal.

Fixed in hrev45705.

Hi, in add-ons/translators/gif/Save Palette.cpp, fTransparentMode initialized incorrectly (pointed by gcc4.8).
​http://cgit.haiku-os.org/haiku/tree/src/add-ons/translators/gif/SavePalette.cpp#n242

/home/haiku/haiku/haiku/src/add-ons/translators/gif/SavePalette.cpp: In constructor 'SavePalette::SavePalette(BBitmap*, int32)':
/home/haiku/haiku/haiku/src/add-ons/translators/gif/SavePalette.cpp:242:1: error: 'SavePalette::fTransparentMode' is initialized with itself [-Werror=init-self]
 SavePalette::SavePalette(BBitmap *bitmap, int32 maxSizeInBits)
 ^
cc1plus: all warnings being treated as errors

If I do a ls -lsa on the NFS2 even for empty files a very big value is shown
in the first column. See in the attached screenshot.
When copying via Tracker the progress is messed up with the same big values.
This is gcc4 build of