On Mon, Mar 1, 2010 at 8:22 AM, surya prakash <[email protected]> wrote:
> We are running a multithreaded linux application (NMS). There were 48
> threads running which parallely sends the SNMP request and processes the
> same.
>
> In one of the thread, there were a write to stderror from SNMP
> ----------------- lwp# 47 / thread# 47 --------------------
> fea46d38 write (2, fbb7aaa8, 35)
> fea19318 _dowrite (fbb7aaa8, 35, 246ab0, fbb7a8c8, 6, 4) + 54
> fea1bdac _ndoprnt (1f7854, fbb7a994, fbb7aadd, fbb7aaa8, fbb7a8c8,
> fea55c69) + 28bc
> fea1d040 fprintf (246ab0, 1f7850, fbb7a9a0, 513b8, fea19358, fea6e32c) +
> e0
> 0012c7a8 log_handler_stdouterr (cadb78, 4, fbb7aaa8, 1, fbb7aadd, 10) + 98
> 0012ca04 snmp_log_string (4, fbb7aaa8, fbb7aadd, fbb7af74, 7ffffc00,
> fea6e32c) + 74
> 0012caa0 snmp_vlog (0, 1ffe78, fbb7af74, fe8ab000, fea71840, 0) + 58
> 0012cb40 snmp_log (4, 1ffe78, 1fff60, 0, 0, 0) + 1c
> 00130fa4 snmp_call_callbacks (0, 5, 26253b0, 80808000, 248400, 0) + 30c
> 00116394 snmp_sess_copy (8204f8, fbb7b078, fbb7b060, 0, 0, a1) + 1f8
> 001177a4 snmp_sess_open (fbb7b838, 3f4ccccd, fbb7b938, 293c290, ff0000,
> fbb7b930) + 10
>
> This stderror write creates a race condition where it blocks other thread
> in execution (lwp_wait).
>
The only possible cause I know of that can cause fprintf() to deadlock (when
stderr is not redirected) is memory corruption of the glibc internal data
structures. Have you already verified your application with Valgrind ?
Bart.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
