Forum Discussion

Vladimir_Akhmarov's avatar
May 31, 2024

SIGSEGV on 15.1.10.x

Hello, community!

 

Does someone experience SIGSEGV exceptions on 15.1.10.x branch?

 

We have 4200v and after standby device upgrade from 151.9.1 to [15.1.10.0, 15.1.10.2, 15.1.10.3 or 15.1.10.4] it fails with SIGSEGV. It is standby device and the only traffic arrives is DNS Authoritative requests-responses

 

Usually /var/log/tmm contains such messages (extracted from 15.1.10.4):

<13> 2024-06-01T00:08:37.325+03:00 bigip1 notice Product: BIG-IP

<13> 2024-06-01T00:08:37.325+03:00 bigip1 notice Version: 15.1.10.4

<13> 2024-06-01T00:08:37.325+03:00 bigip1 notice Build: 0.0.5

...

<13> 2024-06-01T00:08:37.326+03:00 bigip1 notice platform=C113

<13> 2024-06-01T00:08:37.326+03:00 bigip1 notice ** SIGSEGV **

...

<13> 2024-06-01T00:08:37.326+03:00 bigip1 notice RIP: 0x00007ff1c3c76f11 EFLAGS: 0x0000000000013283

...

<13> 2024-06-01T00:08:37.339+03:00 bigip1 notice 7ff1c3b0d000-7ff1c3ccb000 r-xp 00000000 fd:12 41615                      /usr/lib64/libc-2.17.so

<13> 2024-06-01T00:08:37.339+03:00 bigip1 notice 7ff1c3ccb000-7ff1c3eca000 ---p 001be000 fd:12 41615                      /usr/lib64/libc-2.17.so

<13> 2024-06-01T00:08:37.339+03:00 bigip1 notice 7ff1c3eca000-7ff1c3ece000 r--p 001bd000 fd:12 41615                      /usr/lib64/libc-2.17.so

<13> 2024-06-01T00:08:37.339+03:00 bigip1 notice 7ff1c3ece000-7ff1c3ed0000 rw-p 001c1000 fd:12 41615                      /usr/lib64/libc-2.17.so

 

If I correctly understand backtrace it catches SIGSEGV inside libc code

 

Unfortunately F5 and partners was not able to quote next year of support contract and currently we do not have any option to submit core file for analysis to F5. According to https://my.f5.com/manage/s/article/K10062 it is more likely some kind of software bug. No matching or similar Bug Id was found on https://my.f5.com/manage/s/bug-tracker

 

Maybe someone on the community experienced the same issue and could guide me what should be disabled/enabled on the box to avoid this bug? Or maybe someone has EngHF with the fix :)

1 Reply

  • After some digging I found that issue was caused by standard TCP virtual server with DNS profile attached

     

    ltm profile dns TEST_dns {
        app-service none
        defaults-from dns
        unhandled-query-action drop
        use-local-bind no
    }
    ltm virtual-address 192.0.2.1 {
        address 192.0.2.1
        floating disabled
        mask 255.255.255.255
        traffic-group traffic-group-local-only
        unit 0
    }
    ltm virtual TEST_tcp {
        destination 192.0.2.1:domain
        ip-protocol tcp
        mask 255.255.255.255
        profiles {
            TEST_dns { }
            f5-tcp-lan {
                context serverside
            }
            f5-tcp-wan {
                context clientside
            }
        }
        serverssl-use-sni disabled
        source 0.0.0.0/0
        translate-address disabled
        translate-port disabled
    }

     

    No matter this config is applied to active or standby device - after some time device cores

    Currently we have 29 zonerunner zones, 27 dnssec signed zones and 36 wide IPs

    Disabling DNSSEC or GSLB or DNS Express does noting

     

    Hope someone could point F5 Product Development on this thread and maybe they could fix this issue with next BIG-IP releases

    :)