occasional valgrind reports for handle_sig_alarm on 32-bit ARM
От | Tomas Vondra |
---|---|
Тема | occasional valgrind reports for handle_sig_alarm on 32-bit ARM |
Дата | |
Msg-id | 15f9bc32-db03-8f60-5fea-eb0b080a0619@enterprisedb.com обсуждение исходный текст |
Ответы |
Re: occasional valgrind reports for handle_sig_alarm on 32-bit ARM
|
Список | pgsql-hackers |
Hi, I've been running a lot of valgrind tests on 32-bit arm recently, and from time to time I get a failure in handle_sig_alarm like this: ==13605== Use of uninitialised value of size 4 ==13605== at 0x88DA98: handle_sig_alarm (timeout.c:457) ==13605== by 0xFFFFFFFF: ??? ==13605== Uninitialised value was created by a heap allocation ==13605== at 0x8A0374: MemoryContextAllocExtended (mcxt.c:1149) ==13605== by 0x86A187: DynaHashAlloc (dynahash.c:292) ==13605== by 0x86CB07: element_alloc (dynahash.c:1715) ==13605== by 0x86A9E7: hash_create (dynahash.c:611) ==13605== by 0x8A1CE3: EnablePortalManager (portalmem.c:122) ==13605== by 0x8716CF: InitPostgres (postinit.c:806) ==13605== by 0x653F63: PostgresMain (postgres.c:4141) ==13605== by 0x5651CB: BackendRun (postmaster.c:4461) ==13605== by 0x564A43: BackendStartup (postmaster.c:4189) ==13605== by 0x560663: ServerLoop (postmaster.c:1779) ==13605== by 0x55FE27: PostmasterMain (postmaster.c:1463) ==13605== by 0x4107F3: main (main.c:200) ==13605== { <insert_a_suppression_name_here> Memcheck:Value4 fun:handle_sig_alarm obj:* } or (somewhat weird) ==23734== Use of uninitialised value of size 4 ==23734== at 0x88DDC8: handle_sig_alarm (timeout.c:457) ==23734== by 0xFFFFFFFF: ??? ==23734== Uninitialised value was created by a stack allocation ==23734== at 0x64CE2C: EndCommand (dest.c:167) ==23734== { <insert_a_suppression_name_here> Memcheck:Value4 fun:handle_sig_alarm obj:* } It might be a valgrind issue and/or false positive, but I don't think I've seen such failures before, so I'm wondering if this might be due to some recent changes? It's pretty rare, as it depends on the timing of the signal being just "right" (I wonder if there's a way to increase the frequency). regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: