• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

DragonflyBSD considers adopting the OpenBSD malloc

Didn't totally understand that pkgsrc problem. Does that mean that pkgsrc has hitherto-undiscovered bugs that can be investigated and fixed?
 
Originally posted by: kamper
Didn't totally understand that pkgsrc problem. Does that mean that pkgsrc has hitherto-undiscovered bugs that can be investigated and fixed?
Click to expand...

There wasn't enough information in the email to figure it out. It could be problems with pkgsrc, any of the build tools, or even the programs themselves.
 
But one way or another, it means that the new malloc is working, which can't be a bad thing. They're developers. They'll fix the problems.
 
Originally posted by: kamper
But one way or another, it means that the new malloc is working, which can't be a bad thing. They're developers. They'll fix the problems.
Click to expand...

Yeah, I hope they import it and work out the issues instead of deciding it's too icky to mess with...
 
Agreed. Given that their whole MI is to get rid of cruft and rewrite stuff and that most of their current user base is probably willing to deal with the havoc, it wouldn't make sense not to take it. Matt Dillon seemed pretty keen on accepting it and it hasn't caused too many problems in OpenBSD 3.8 has it?
 
Originally posted by: kamper
Agreed. Given that their whole MI is to get rid of cruft and rewrite stuff and that most of their current user base is probably willing to deal with the havoc, it wouldn't make sense not to take it. Matt Dillon seemed pretty keen on accepting it and it hasn't caused too many problems in OpenBSD 3.8 has it?
Click to expand...

I didn't notice any. The stuff in base was ready for it though, and I'm pretty sure some extensive work was done by the port maintainers to make sure things were working.
 
G ``Guard''. Enable guard pages and chunk randomization. Each
page size or larger allocation is followed by a guard page that
will cause a segmentation fault upon any access. Smaller than
page size chunks are returned in a random order.
Click to expand...

From malloc.conf(3)

I think it's mostly used to help debug naughty applications (although I think I run it "production" on my home machines).
 
I see. So (you think) it's enabled in -current in obsd (or did you tweak it and forget?). I have nothing set in 3.8 stable.

I remember reading about this but forget the answer: are heap overflow attacks a potential threat? ie. are there security benefits from enabling G?

I wish I'd had this malloc impl when I was learning c in 1st year 😛
 
Originally posted by: kamper
I see. So (you think) it's enabled in -current in obsd (or did you tweak it and forget?). I have nothing set in 3.8 stable.
Click to expand...

Tweak and forget. I typically use a number of flags, AJGF, IIRC. My zaurus's batteries are too low for me to check if I have them set on there at the moment. I might have removed them because a non-ports/package program didn't like them. 😛

I remember reading about this but forget the answer: are heap overflow attacks a potential threat? ie. are there security benefits from enabling G?

I wish I'd had this malloc impl when I was learning c in 1st year 😛
Click to expand...

They are a potential threat, and I'm pretty sure G can help with security.

EDIT: I'm using AFGJPR at the moment.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top