From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27321 invoked by alias); 14 Oct 2010 12:05:58 -0000 Received: (qmail 27310 invoked by uid 22791); 14 Oct 2010 12:05:57 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from smtp-out1.starman.ee (HELO mx1.starman.ee) (85.253.0.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 Oct 2010 12:05:44 +0000 Received: from UserPC (82.131.67.188.cable.starman.ee [82.131.67.188]) by mx1.starman.ee (Postfix) with SMTP id 419093F40DD for ; Thu, 14 Oct 2010 15:05:39 +0300 (EEST) Message-ID: <6B1F55F835FC4A81A2E9F991800A4E80@UserPC> From: =?windows-1257?B?SvxyaSBQ9WxkcmU=?= To: Subject: Thread stuck in ioctl Date: Thu, 14 Oct 2010 12:05:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1257"; reply-type=original Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-10/txt/msg00047.txt.bz2 Hello, DVB hardware platform is using ioctl based interface to engage kernel calls from userspace. The code base is rather large and extends inside kernel to two separate processors - one for video and another for audio decoding. During bad signal quality one of these calls locks up causing userspace thread to do the same. After some time watchdog resets device. Although it is possible to add debug printouts to this interface doing so would cause a lot of traffic and also shift process timings. Embedded platforms are relatively slow and lot of debug info chokes them pretty fast. It would be very helpful to print backtrace of stuck thread. It is possible to start gdb debugging in non-stop mode. After ioctl locks switch to locked thread with "thread nr" command works but nothing can be done as it is running. Stopping thread with "interrupt" command does not succeed because breakpoint in thread is never reached causing gdb to wait forever. Scheduler should be aware of locked thread environment. Can you tell me if this is fundamental issue or can it be overcome? It is ok that program cannot be debugged further, only information about stuck thread backtrace is required. HW platform MIPS32r2 300 MHz, Linux 2.6.18, gdb 7.2 Sincerely, Jüri Põldre.