[Info-Ingres] Mutex: ULH Sem?
Martin Bowes
Hi All,
Running II 9.2.0 (a64.lnx/143)NPTL + p13556
I've just had a server mutex all its connections waiting for a ULH Sem…whatever that is.
The problems first occurred after a standard user connection had a SIGSEGV in the RDF.
bb1.ctsu::[39142 , d3d30200]: Tue Dec 22 11:32:08 2009 Segmentation Violation (SIGSEGV) @PC 00000000004cdc0d
RSP 00000000413bcca0 RBP 00000000413bccd0 RSI 00002aaacd369f78
RDI 00002aaacd369f78 RAX 0000000000000000 RBX 00000000413bd0c8
RCX 000000000000424a RDX 0000000000000000
-----------BEGIN STACK TRACE------------
0: 413bccd0 iidbms(rdu_r_deulh+0xa6) [0x4cdc0d]( ... )
1: 413bcd00 iidbms(rdu_drop_attachments+0x174) [0x4cd60c]( ... )
2: 413bcd40 iidbms [0x4c398c] <static function, no info available>
3: 413bcd90 iidbms(invalidate_relcache+0x3a1) [0x4c3f08]( ... )
4: 413bdd20 iidbms [0x4b3548] <static function, no info available>
5: 413bdd80 iidbms(rdf_gdesc+0x13b) [0x4b4e58]( ... )
6: 413bed70 iidbms(rdf_call+0x29b) [0x4b06b6]( ... )
7: 413bf030 iidbms(pst_showtab+0x386) [0x544ea6]( ... )
8: 413bf0a0 iidbms(pst_sent+0xba) [0x540a86]( ... )
9: 413bf110 iidbms(psl0_orngent+0x97) [0x7c6381]( ... )
10: 413bf170 iidbms(psl_orngent+0x4d) [0x7c628b]( ... )
11: 413bf480 iidbms(psls27iftn+0xb59) [0x7f81a3]( ... )
12: 413c1f20 iidbms(pslsparse+0xa33) [0x7d2437]( ... )
13: 413c2140 iidbms(psq_parseqry+0x9f7) [0x53179a]( ... )
14: 413c29f0 iidbms(psq_recreate+0x3f8) [0x5327d0]( ... )
15: 413c2c20 iidbms(psq_call+0x44e) [0x52b8be]( ... )
16: 413c5050 iidbms(scs_sequencer+0x2768) [0x4835e8]( ... )
17: 413cd1d0 iidbms(CSMT_setup+0x50e) [0x6dc1ce]( ... )
-----------END STACK TRACE----------
After which user connections were in trouble.
State: CS_MUTEX ((x) 00002AAACD3117D8)
Mask: OS_tid: 15690 Mutex: ULH sem
Anyone got anyideas?
BTW. Show mutex showed nothing. I had to stop and restart the installation to get things moving again.
Martin Bowes
Karl Schendel
On Dec 22, 2009, at 7:40 AM, Martin Bowes wrote:
> Hi All,
>
> Running II 9.2.0 (a64.lnx/143)NPTL + p13556
> I've just had a server mutex all its connections waiting for a ULH Sem�whatever that is.
>
> The problems first occurred after a standard user connection had a SIGSEGV in the RDF.
> bb1.ctsu::[39142 , d3d30200]: Tue Dec 22 11:32:08 2009 Segmentation Violation (SIGSEGV) @PC 00000000004cdc0d
> RSP 00000000413bcca0 RBP 00000000413bccd0 RSI 00002aaacd369f78
> RDI 00002aaacd369f78 RAX 0000000000000000 RBX 00000000413bd0c8
> RCX 000000000000424a RDX 0000000000000000
>
> -----------BEGIN STACK TRACE------------
> 0: 413bccd0 iidbms(rdu_r_deulh+0xa6) [0x4cdc0d]( ... )
> 1: 413bcd00 iidbms(rdu_drop_attachments+0x174) [0x4cd60c]( ... )
I am 99% sure that this has a fix. There were a couple rounds of
fixes in RDF, one specifically dealing with drop-attachments
and one having to do with concurrency goofs in reference
counting in RDF. I'd check with support and see if you can get an
updated patch, or have one made.
ULH = Utility Hash. It's a semi-generic hash table implementation
used by RDF and QEF. (QEF uses it to store saved query plans.)
Karl
Martin Bowes
Merry Xmas etc...
Marty
-----Original Message-----
From: info-ingr...@kettleriverconsulting.com
[mailto:info-ingr...@kettleriverconsulting.com] On Behalf Of Karl
Schendel
Sent: 22 December 2009 12:51
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] Mutex: ULH Sem?
On Dec 22, 2009, at 7:40 AM, Martin Bowes wrote:
> Hi All,
>
> Running II 9.2.0 (a64.lnx/143)NPTL + p13556
> I've just had a server mutex all its connections waiting for a ULH
Sem...whatever that is.
>
> The problems first occurred after a standard user connection had a
SIGSEGV in the RDF.
> bb1.ctsu::[39142 , d3d30200]: Tue Dec 22 11:32:08 2009
Segmentation Violation (SIGSEGV) @PC 00000000004cdc0d
> RSP 00000000413bcca0 RBP 00000000413bccd0 RSI 00002aaacd369f78
> RDI 00002aaacd369f78 RAX 0000000000000000 RBX 00000000413bd0c8
> RCX 000000000000424a RDX 0000000000000000
>
> -----------BEGIN STACK TRACE------------
> 0: 413bccd0 iidbms(rdu_r_deulh+0xa6) [0x4cdc0d]( ... )
> 1: 413bcd00 iidbms(rdu_drop_attachments+0x174) [0x4cd60c]( ... )
I am 99% sure that this has a fix. There were a couple rounds of
fixes in RDF, one specifically dealing with drop-attachments
and one having to do with concurrency goofs in reference
counting in RDF. I'd check with support and see if you can get an
updated patch, or have one made.
ULH = Utility Hash. It's a semi-generic hash table implementation
used by RDF and QEF. (QEF uses it to store saved query plans.)
Karl
_______________________________________________
Info-Ingres mailing list
Info-...@kettleriverconsulting.com
http://ext-cando.kettleriverconsulting.com/mailman/listinfo/info-ingres