Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Turns out it was an old queue and deuling pq commands. Stopping with ldmadmin, recreating the queue, and restarting, solved the problem. -- John Trostel Director - Severe Storms Research Center Georgia Tech Research Institute Atlanta, GA -------- Original message -------- From: Gilbert Sebenste <gilbert@xxxxxxx> Date: 11/3/16 14:42 (GMT-05:00) To: "Trostel, John M." <john.trostel@xxxxxxxxxxxxxxx>, ldm-users@xxxxxxxxxxxxxxxx Subject: RE: pqinsert and pqcheck segfaults Hi John, While it shouldn't do that, what is the size of the queue? Gilbert From: ldm-users-bounces@xxxxxxxxxxxxxxxx [mailto:ldm-users-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Trostel, John M. Sent: Thursday, November 03, 2016 9:26 AM To: ldm-users@xxxxxxxxxxxxxxxx Subject: [ldm-users] pqinsert and pqcheck segfaults I'm now getting seg faults on both an older build and a fresh compile of LDM (6.13.5 and 6.12.14). This all worked before I had to rebuild my system from scratch (Ubuntu 16.04 LTS) All compilation and configuration seems to work fine. Output of gdb: Reading symbols from ./pqcheck...done. (gdb) run Starting program: /home/ldm/ldm-6.13.5/bin/pqcheck [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 20161103T142135.640016Z pqcheck[16469] NOTE pqcheck.c:150:main() Starting Up (16469) Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7b799d7 in ctl_gopen ( path=0x7ffff7dd47a0 <queuePath> "/home/ldm/var/queues/ldm.pq", pq=0x616440) at pq.c:4744 4744 if (!(pq->rlp->nalloc == pq->nalloc && pq->tqp->nalloc == pq->nalloc -- John Trostel Director - Severe Storms Research Center Georgia Tech Research Institute Atlanta, GA 30332-0857
ldm-users
archives: