This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Unidata User Support <address@hidden> >Organization: Unidata Program Center/UCAR >Keywords: 200512081502.jB8F2Y7s029370 LDM 20051207 5Z assertion failure Hi Gerry, I got your voicemail... I just logged onto sasquatch to take a look at the LDM exits you noted in your voicemail. The failure December 8: ldmd.log.3: ... Dec 08 05:32:11 sasquatch bigbird[6159] ERROR: assertion "n > 0" failed: file "pq.c", line 2259 ... Dec 08 05:34:17 sasquatch rpc.ldmd[6153] NOTE: child 6159 terminated by signal 6 Dec 08 05:34:17 sasquatch rpc.ldmd[6153] NOTE: Killing (SIGINT) process group Dec 08 05:34:17 sasquatch rpc.ldmd[6153] NOTE: SIGINT ... is the same that was reported by 4 sites on December 7. Steve (who has been at the AGU meeting in San Francisco) commented on this failure to another user: From address@hidden Thu Dec 8 11: 44:34 2005 Amazing! The product-queue module contains a bad assert() that's activated if the first four bytes of the MD5 checksum of a data-product (the data-product's signature) are all zeros. In order for this to occur, the LDM package must also have been compiled with assertions enabled (which is not the default). Apparently, this is the first such occurrence in eleven years. I've removed the offending assertion and will make a new release when I return. Regards, Steve Emmerson I don't know how Steve built the version of the LDM you are using (6.4.2), but I found the following in the ~ldm/ldm-6.4.2/src/macros.make file: CFLAGS = -g -m64 CONFIGURE_CPPFLAGS = -UNDEBUG GDBMLIB = CONFIGURE_LIBS = The -UNDEBUG setting of CONFIGURE_CPPFLAGS was most likely the culprit in activating assertions, and it was an assertion that caused the LDM to exit. Steve may have set this to try and capture errant behavior on sasquatch (he/you were trying to figure out previous failures you were seeing). The other LDM exits I saw recently were caused from someone stopping the LDM. In at least one case, this was due to fflush errors from pqact because a file system was full: from ~ldm/logs/ldmd.log.1: Dec 09 16:23:55 sasquatch pqact[3625] ERROR: fflush: /usr/local/ldm/data/ddplus/marine/05120916.CGDUMP: No space left on device Dec 09 16:23:57 sasquatch last message repeated 5 times Dec 09 16:23:57 sasquatch rpc.ldmd[3622] NOTE: SIGTERM Dec 09 16:23:57 sasquatch rpc.ldmd[3622] NOTE: Terminating process group The question now is if the LDM has been exiting in any other ways that I did not see? If no, then it may be a good time to (re)build either the version you are already using (6.4.2) or the latest available (6.4.4) with assertions turned off. One last comment: Steve noted that he has already turned off the offending assertion and will make a new release when he gets back to the office. I am not sure if this will be today (he is not in yet) or Monday, but I think that Monday is more likely. So, what would you like to do at this point: - rebuild your current LDM without assertions - build the latest LDM without assertions - wait for Steve's new release Cheers, Tom