OpenQNX :: The QNX Community Portal

Hello, All!

Is it possible somehow to disable core dumping of mmaped device memory, in
global OS/dumper settings or via some undocumented mmap flag, doesn't
matter.
It's really annoying to wait while dumper finishes its job when driver
segfaults with one gigabyte of mmaped PCI aperture memory, in most cases -
it's not important what device's memory contain.

Thanks in advance ...
... or thanks for ignorance :)

With best regards, Mike Gorchak. E-mail: mike@malva.ua

How do you know what memory is 'device' memory. I guess we could come
up with a scheme in which you
look at the asinfo entries, but that would be hard to enforce.

Right now it uses the heuristic that PROT_NOCACHE memory is device
memory and should not be dumped,
although it's somewhat stupid in that it still writes it to the logfile
(as -1s) - it would be better
to put out a PT_LOAD segment with a zero filesz (or just omit it
altogether)

You can checkout services/dumper from the repository and hack it to be
aware of whatever method
you like for now - I'm willing to take suggestions/patches though.

Mike Gorchak wrote:
Hello, All!

Is it possible somehow to disable core dumping of mmaped device
memory, in global OS/dumper settings or via some undocumented mmap
flag, doesn't matter.
It's really annoying to wait while dumper finishes its job when driver
segfaults with one gigabyte of mmaped PCI aperture memory, in most
cases - it's not important what device's memory contain.

Thanks in advance ...
... or thanks for ignorance :)

With best regards, Mike Gorchak. E-mail: mike@malva.ua

Hello, Colin!

CB> I've just committed a fix for this. I've made the default to not dump
CB> out memory that is marked as being MAP_PHYS (but isn't also MAP_ANON).

CB> You can force them to be dumper out again by adding the -P option.

CB> The change is in trunk/services/dumper/dumper.c repo version 154191 -
CB> it should be visible in a short while.

Wow, thank you ! :)

Colin, do you have also any suggestions about wbinvd x86 cpu instruction
execution (problem was described by me in the previous newsletter in this
group) ? Does PROT_NOCACHE mmap option will act the same as continually
wbinvd execution after writings to that mmaped memory ?

With best regards, Mike Gorchak. E-mail: mike@malva.ua

"Mike Gorchak" <mike@malva.ua> wrote in message
news:fcsu5m$7fk$1@inn.qnx.com...
Hello, Colin!

CB> I've just committed a fix for this. I've made the default to not dump
CB> out memory that is marked as being MAP_PHYS (but isn't also MAP_ANON).

CB> You can force them to be dumper out again by adding the -P option.

CB> The change is in trunk/services/dumper/dumper.c repo version 154191 -
CB> it should be visible in a short while.

Wow, thank you ! :)


Who said this would be a non event

Colin, do you have also any suggestions about wbinvd x86 cpu instruction
execution (problem was described by me in the previous newsletter in this
group) ? Does PROT_NOCACHE mmap option will act the same as continually
wbinvd execution after writings to that mmaped memory ?

With best regards, Mike Gorchak. E-mail: mike@malva.ua

Who said this would be a non event ;-)

Oh, just some curmudgeon who's always looking on the downside - apart from
him, everyone
seems to be happy! ;-P

Who said this would be a non event
Oh, just some curmudgeon who's always looking on the downside - apart from
him, everyone
seems to be happy! ;-P


I had two people in mind I had to look up curmudgeon...

Mario Charest wrote:
Who said this would be a non event
Oh, just some curmudgeon who's always looking on the downside - apart
from him, everyone
seems to be happy! ;-P


I had two people in mind I had to look up curmudgeon...

Did I spell it correctly?

--
cburgess@qnx.com

Hello, Colin!

Wow, thank you ! :)

Colin, do you have also any suggestions about wbinvd x86 cpu instruction
execution (problem was described by me in the previous newsletter in this
group) ? Does PROT_NOCACHE mmap option will act the same as continually
wbinvd execution after writings to that mmaped memory ?