From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 91082384AB4D; Thu, 16 May 2024 03:12:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 91082384AB4D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1715829128; bh=BgDTWk0yCmTdVGk3JBG5GXB9hU3zShGVULXIASwliZc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UcsG2ALbcI+PGUZTNNIGh/RtoIL+GHu0fTw6d7IVrW30DX/pPLXUMZVHq49k5FHqd 0JyiDh/xpjJ2so6aiy/vvg+FBgm+ME3I0i/WnX/b7FeSemfoMBZ/FtjNZ87RQ11SQk C3EgIuqeq/CJb4+XjFsAQc1jbM8XZzA8KlEh9bNU= From: "liaozhicai at cigtech dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/31732] ld.so is trapped in __libc_csu_init function, no return or forward when load a normal ELF process Date: Thu, 16 May 2024 03:12:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.30 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: liaozhicai at cigtech dot com X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31732 --- Comment #2 from Liao Zhicai --- (In reply to Florian Weimer from comment #1) > Sorry, could you describe what you are doing in more detail? Thanks. >=20 > We have not received a report of a similar issue, as far as I can recall. we try to load another process in our program, coding as follows, if ((pid =3D fork()) < 0)=20 { ASSERT(0); } // In child process if (0 =3D=3D pid)=20 { setpriority(0, 0, (INT32)priority - 20); sprintf_s(priStr, sizeof(priStr), "%d", priority); sprintf_s(stackStr, sizeof(stackStr), "%d", stackSize); paraList[0] =3D (CHAR*)execFileName; paraList[1] =3D "-p"; paraList[2] =3D priStr; paraList[3] =3D "-s"; paraList[4] =3D stackStr; paraList[5] =3D NULL; execve(execFileName, paraList, env); } as a result, the new process can't be found occationally, then we trace the routine, it is found that execv has transfered the control right to ld.so, and in function LIBC_START_MAIN it has come to init function(here init is __libc_csu_init) and trapped there, no return, no forward, because we found output message "initialize program:" and no "transferring control:", as follows, 364:=20=20=20=20=20 364: calling init: /lib/libm.so.6 364:=20=20=20=20=20 364:=20=20=20=20=20 364: --ljh--initialize program start: /usr/bin/MecMgr 364:=20=20=20=20=20 Starting Application: 0x00003000, /usr/bin/MecMgr................ the next, we added some printf clauses in __libc_csu_init trying to find out where it is when error occured, but unforturnately the issue can't be reproduced at this time. we also have tried to print what the function __libc_csu_init looked like before it is executed in function LIBC_START_MAIN, unforturnately the issue can't be reproduced again. it seems that if we do any modification in or before the function __libc_csu_init, then the issue disappears. --=20 You are receiving this mail because: You are on the CC list for the bug.=