3 Replies Latest reply: Jan 20, 2012 8:59 PM by mgh RSS

    format core dumps

      High uptime (~2 years) Solaris 10 update 4 data ingest system just brought up to current patch level (~300 patches). Now, "format" command core dumps after selecting any disk unless NOINUSE_CHECK=1 is set. Call trace ends with the following -- any ideas?

      1831/1: getmsg(7, 0x08045E10, 0x08045E1C, 0x08045E30) = 0
      1831/1: getgroups(0, 0x00000000) = 11
      1831/1: sysinfo(SI_HOSTNAME, "xxx.xxx.xxx.xxx", 255) = 24
      1831/1: getuid() = 0 [0]
      1831/1: getgid() = 0 [0]
      1831/1: getgroups(11, 0x08045FD0) = 11
      1831/1: Incurred fault #6, FLTBOUNDS %pc = 0xC4D961E1
      1831/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x00756465
      1831/1: Received signal #11, SIGSEGV [default]
      1831/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x00756465

      It's clear we have a workaround, but anyone have an idea what's at the heart of the problem?
        • 1. Re: format core dumps
          I am having the exact same issue using Solaris 10 update 10 and the January recommended patch cluster. I opened a service request with Oracle about this.
          • 2. Re: format core dumps
            After applying the most current recommended patch cluster it seems that patch 145900-06 causes format to dump core. Since this is an older patch (listed in MOS as 7 weeks old) I assume this is the result of a combination of patches (maybe the update 10 patch 144501-19?). I am still working with Oracle support to get this fixed. Stay tuned.
            • 3. Re: format core dumps
              Last update on this. The most current revision of patch 145900-08 addressed the problem. Somehow previous releases of this patch broke libmeta and cause core dumps in things like format, zpool, and metaset if the node name is a fully qualified hostname.