Segfault in gpt3_1 (lsq) on second pass after redig. static PPP, mode S

[dibg]

Segfault in gpt3_1 (lsq) on second pass after redig — static PPP, mode S

Summary

lsq segfaults reproducibly on the second invocation (post-redig) inside gpt3_1.f90:302 (undu = u(ix)), called from troposphere_delay.f90:63. The first lsq pass and redig both finish cleanly; the crash only happens after re-running lsq on the cleaned residuals. Reproducible on consecutive days from the same static receiver.

Environment

• PRIDE PPP-AR version: 3.2.7
• Commit: dcc5490 (origin/master, fast-forwarded today)
• Built from source: yes, via ./install.sh after git pull
• OS: Linux 6.12.85-1-MANJARO (x86_64)
• Shell: zsh
• Compiler: GNU Fortran (GCC) 15.2.1 20260209

Reproduction

Command:

pdp3 -m S gps_20260429.26O

Same crash on gps_20260430.26O (next day, same site).

Site / config:

• Site name: 0000 (default; not in any IGS table)
• Static receiver in southern Europe, ellipsoidal height ~170 m (exact coords withheld; can share privately if needed for repro)
• Mode S (static), AR A, interval 10 s, span 24 h + 20 s
• Frequencies: G12 R12 E15 C26 J12
• Antenna in RINEX header: ADVNULLANTENNA NONE (not in ANTEX → zero antenna applied)
• No oceanload coefficients for site 0000 → falls back to zhang model
• No GNSS J observations / no QZSS orbits → warned, presumably skipped

Output (relevant excerpt)

===> Data cleaning ...
(2026-05-06 02:05:41) lsq config.5H8WAwORNc ".../gps_20260429.26O" execution ok
(2026-05-06 02:06:32) redig res_2026119 -jmp 400 -sht 60 execution ok
%%%+RMS OF RESIDUALS---PHASE(MM)
%%%-RMS OF RESIDUALS---PHASE(MM)
Newly removed observations:        478    0.17%
Newly inserted ambiguities:          0    0.00%
(2026-05-06 02:06:33) lsq config.5H8WAwORNc ".../gps_20260429.26O" execution failed
:: Here is the output:

 File name: mhm_0000
 Does the file exist?  F
###WARNING(oceanload_coef): no oceanload coefficients for 0000. Use oceanload model(zhang) instead.
STA: 0000 .../gps_20260429.26O   91.2%
###WARNING(rdatx): Antenna not found ADVNULLANTENNA  NONE
$$$MESSAGE(rdatx): zero antenna applied instead

 size of Normal Matrix :      51
 size of NC Parameter  :       3
 size of NP Parameter  :       8

 ALL PARAMETERS
   1   0 0000     STAPX
   2   0 0000     STAPY
   3   0 0000     STAPZ
   4   0 0000     RECCLK_G_WNO
   5   0 0000     RECCLK_R_WNO
   6   0 0000     RECCLK_E_WNO
   7   0 0000     RECCLK_C_WNO
   8   0 0000     RECCLK_3_WNO
   9   0 0000     ZTDSTO
  10   0 0000     HTGCPWC:43200
  11   0 0000     HTGSPWC:43200

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f454f424418 in ???
#1  0x7f454f4233a5 in ???
#2  0x7f454ee3e2cf in ???
#3  0x56528fb16a0e in master.0.gpt3_1
    at /home/user/Code/PRIDE-PPPAR/src/lib/gpt3_1.f90:302
#4  0x56528fb1919f in gpt3_1_
    at /home/user/Code/PRIDE-PPPAR/src/lib/gpt3_1.f90:1
#5  0x56528fb3b4e0 in troposphere_delay_
    at /home/user/Code/PRIDE-PPPAR/src/lib/troposphere_delay.f90:63
#6  0x56528faf8120 in lsq
    at /home/user/Code/PRIDE-PPPAR/src/lsq/lsq.f90:345
#7  0x56528fade49e in main
    at /home/user/Code/PRIDE-PPPAR/src/lsq/lsq.f90:623

The same backtrace appears on day 120 (commit dcc5490, recompiled).

Suspected cause

The crash is at:

! gpt3_1.f90:302
undu = u(ix)

where ix = (ipod-1)*360 + ilon. The fault is an array out-of-bounds read on u, suggesting that ipod and/or ilon are out of the expected [1,91] / [1,360] ranges by the time gpt3_1 is called from troposphere_delay.f90:63 on the second lsq pass.

Possible triggers:

• Bad station coords (NaN / wildly out of range) carried into the second pass after redig.
• An uninitialized state when no mhm_<site> file exists (Does the file exist? F).
• An interaction with the zero antenna applied fallback path.

A defensive bounds check on ipod/ilon (or on ix before indexing u) would at minimum convert this into a clear error message instead of a segfault.

Reproducer

I can share the following privately (the RINEX header contains the precise station coordinates, which I'd prefer not to post on a public tracker):

• The two RINEX .26O observation files (DOY 119 and 120 of 2026)
• The brdm navigation files used
• The exact config.<…> written by pdp3

Please let me know the best private channel (email, etc.) and anything else that would help diagnose this.

[PrideLab]

Hello, thanks for the information. Could you send your data to our email, pride@whu.edu.cn, from which we could diagnose?

[PrideLab]

@dibg Would you send us your data and then we could check the problem? pride@whu.edu.cn

[dibg]

@PrideLab Hi, i send 3 files: 0428, 0429, 0501. The first two have the issue the third one is not.