Re: "Kernel" dumps.

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 01/12/05

  • Next message: Xin LI: "Re: "Kernel" dumps."
    Date: Wed, 12 Jan 2005 14:32:43 +0000 (GMT)
    To: Pawel Jakub Dawidek <pjd@FreeBSD.org>
    
    

    On Wed, 12 Jan 2005, Pawel Jakub Dawidek wrote:

    > We need improve our dumps, really.
    >
    > First of all they are too big, because we dump whole memory. Second of
    > all, they are not safe for our users.
    >
    > We should implement two things:
    >
    > - dumping only kernel pages (dump is smaller and without sensitive data
    > from userland processes);
    > - add a malloc(9) flag M_NOUMP which will prevent from dumping
    > pages with sensitive data (e.g. GBDE keys).
    >
    > Any VM-skilled volunteers? Pretty please...

    While I don't object in principle to these changes (and recognize why they
    would be quite beneficial), an important consideration in any touching of
    the debugging code is minimizing the chances that corrupt kernel data
    structures will prevent us from gathering debugging information
    effectively. If the dump code has to walk VM data structures extensively,
    that increases the risk that the dump will fail due to an invalid pointer
    dereference, especially if what's being debugged is a VM bug. We already
    enter a temporary mapping for each physical page during the dump process
    so that the pages can be dumped, I guess, so maybe this is not such a big
    issue. However, one of the things that has made FreeBSD a great operating
    system to develop on in the past has been robust and consistent debugging
    tools--the current tools seem a little less robust post-SMPng, largely due
    to relatively minor nits that need to be cleaned up, but I'd hate for them
    to get less reliable if that's avoidable.

    Robert N M Watson

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  • Next message: Xin LI: "Re: "Kernel" dumps."

    Relevant Pages

    • Re: Crashdump Win2k Server
      ... I'm afraid that mini dump is too limited to analyze and obtain enough ... I suggest that you config "Write debugging information" to Complete memory ...
      (microsoft.public.windows.server.general)
    • Re: Exception and GetLastError()
      ... blah blah blah ... e.g. as a mini dump. ... Those dump files can be loaded with windbg from the debugging sdk so that you can analyze the state of a process when an exception occurs. ...
      (microsoft.public.vc.language)
    • Re: WER and managed minidumps
      ... debugger is only looking for native symbols. ... VS2005 debugger always works in native mode when debugging dumps. ... you should use SOS extension in Immediate ... (though note that the information contained in a dump created with WER ...
      (microsoft.public.vsnet.debugging)
    • Re: Memory.dmp
      ... >>The computer has rebooted from a bugcheck. ... >>How can i found out what causes the reboot? ... This means the dump contains ... > code and has to be analyzed using a debugging program. ...
      (microsoft.public.win2000.general)
    • [PATCH 09/44 take 2] [UBI] debug unit header
      ... * the GNU General Public License for more details. ... * UBI debugging unit. ... The debugging prints may also be directed to the console. ... * @vtr: the object to dump ...
      (Linux-Kernel)