Bug#479438: Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
2009/1/28 Daniel Burrows : > I'd like to thank everyone who replied on these bugs over the last > couple years. Especially the people who prodded me into trying out > kernel 2.6.18-6. I've tracked down the bug, or at least I think maybe > I have. There is definitely a bug here, but it seems to be failing > even in cases where it "ought to" work; I suspect that 2.6.18-6 is also > a bit broken. [..] > So, the long and the short of it is: if we just lock the mutex when > we actually need it, that is, when we're about to send a get_input_event > to the main thread, there's no danger of being canceled and leaving the > mutex locked. I've attached a patch that does this; on my computer, it > eliminates the hang. I'll ask the release managers for permission to > apply this patch in Lenny. I can confirm this patch fixes the problem for me. -- Regards, EddyP = "Imagination is more important than knowledge" A.Einstein -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#479438: Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
I'd like to thank everyone who replied on these bugs over the last
couple years. Especially the people who prodded me into trying out
kernel 2.6.18-6. I've tracked down the bug, or at least I think maybe
I have. There is definitely a bug here, but it seems to be failing
even in cases where it "ought to" work; I suspect that 2.6.18-6 is also
a bit broken.
The problem stems from the fact that the input thread, for its entire
execution, holds a lock on a mutex. The purpose of this mutex is to
guard a condition variable and an associated member variable of the
input thread, both of which are used to synchronize the input thread and
the foreground code that actually reads from the keyboard. Reading
input in the foreground was introduced in the patch that introduced this
bug (previously we tried to read in the background; it turns out that
curses updates the display when you read keyboard input, so this led to
simultaneous calls to refresh() and corrupted output).
Unfortunately, the threads wrapper used in cwidget does not provide
any way to push thread cleanup handlers for mutex locks, because the
authors of the POSIX threads spec cunningly made it impossible to embed
these in an RAII C++ object due to their use of a macro. You probably
see where this is going...
Because of the flakiness of pthread_cancel(), cwidget mostly avoids
it. However, it is used in a few places, including when we shut down
the input thread. IIRC, this is done because it's necessary to
interrupt a select(), and cancel() is the main tool at our disposal to
do that. The problem is that, in the words of pthread_cleanup_push(3):
...if a thread exits OR IS CANCELLED while it owns a locked mutex,
the mutex will remain locked forever and prevent other threads
from executing normally. (emphasis mine)
Recall that the only reason this mutex is locked is that we need it
for the condition variable. But if you look at the code of the input
thread, you'll see that the condition variable is only accessed in one
sub-clause of that code. In fact, of the three cancellation points in
that function (counting select(), which isn't one on Linux, and the
bracketing pthread_testcancel() calls, which are), only one of them
occurs in the area where the mutex actually has to be locked, and that's
the line where we actually wait on the condition variable. And it turns
out that wait() *DOES* handle cleanup from cancellation properly.
One unexplained question is why the bug hit even when aptitude
suspended in response to a keystroke. When aptitude was waiting for
a keystroke, the input thread would be blocked in select(), so no
cleanup handlers were installed and the scenario above makes sense.
But when aptitude was waiting for a keystroke, I thought that the
input thread would still be blocked waiting on the input event
condition, and as I noted earlier, that should install a proper cleanup
handler. Another question is why we didn't see this bug in 2.6.26.
I can't think of anything, except that maybe the implementation of
mutexes changed somehow so that they get unlocked when a thread is
canceled.
So, the long and the short of it is: if we just lock the mutex when
we actually need it, that is, when we're about to send a get_input_event
to the main thread, there's no danger of being canceled and leaving the
mutex locked. I've attached a patch that does this; on my computer, it
eliminates the hang. I'll ask the release managers for permission to
apply this patch in Lenny.
Now I just need to reboot into 2.6.26 so that my wireless works and I
can actually send this mail.
Daniel
diff --git a/src/cwidget/toplevel.cc b/src/cwidget/toplevel.cc
index c912ad6..e0b6ab2 100644
--- a/src/cwidget/toplevel.cc
+++ b/src/cwidget/toplevel.cc
@@ -1,6 +1,6 @@
// toplevel.cc
//
-// Copyright 1999-2005, 2007-2008 Daniel Burrows
+// Copyright 1999-2005, 2007-2009 Daniel Burrows
//
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
@@ -446,7 +446,6 @@ namespace cwidget
void operator()()
{
- threads::mutex::lock l(input_event_mutex);
input_event_fired = false;
// Important note: this routine only blocks indefinitely in
@@ -480,6 +479,7 @@ namespace cwidget
}
else
{
+ threads::mutex::lock l(input_event_mutex);
post_event(new get_input_event(input_event_mutex,
input_event_fired,
input_event_condition));
Bug#479438: Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
On Tue, Jan 27, 2009 at 09:46:22PM +0200, Eddy Petrișor was heard to say: > 2009/1/27 Daniel Burrows : > > This is for everyone who can reproduce the bug. > > > > Could you build a libcwidget3 with the attached patch and see what's > > produced in /tmp/cwidget.input.log when you reproduce the bug? If I > > start aptitude, run dpkg once, and exit, I get this: > > > > Starting input thread > > Creating new input thread > > Input thread created > > Stopping input thread > > Destroying existing input thread > > Input thread destroyed > > Starting input thread > > Creating new input thread > > Input thread created > > Stopping input thread > > Destroying existing input thread > > Input thread destroyed > > > Starting input thread > Creating new input thread > Input thread created > Stopping input thread > Destroying existing input thread > Input thread destroyed > Starting input thread > Creating new input thread > Input thread created Thanks. That's more interesting than I expected! I was assuming that the input thread wasn't restarting properly, but it looks like it is. So why aren't we responding to events after that? We're responding to some of them, or the display wouldn't redraw properly; only keyboard events are being dropped. I'll send you another patch with some ad-hoc logging in a bit. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
On Tue, Jan 27, 2009 at 08:12:36PM +0200, Eddy Petrișor was heard to say: > reassign 479438 cwidget > forcemerge 479438 348481 431054 431688 432323 434861 462923 466254 475368 > thanks Thanks for the triage. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#479438: Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
2009/1/27 Daniel Burrows : > This is for everyone who can reproduce the bug. > > Could you build a libcwidget3 with the attached patch and see what's > produced in /tmp/cwidget.input.log when you reproduce the bug? If I > start aptitude, run dpkg once, and exit, I get this: > > Starting input thread > Creating new input thread > Input thread created > Stopping input thread > Destroying existing input thread > Input thread destroyed > Starting input thread > Creating new input thread > Input thread created > Stopping input thread > Destroying existing input thread > Input thread destroyed Starting input thread Creating new input thread Input thread created Stopping input thread Destroying existing input thread Input thread destroyed Starting input thread Creating new input thread Input thread created -- Regards, EddyP = "Imagination is more important than knowledge" A.Einstein -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
2009/1/27 Daniel Burrows : > This is for everyone who can reproduce the bug. > > Could you build a libcwidget3 with the attached patch and see what's > produced in /tmp/cwidget.input.log when you reproduce the bug? If I > start aptitude, run dpkg once, and exit, I get this: I tried to grab the git repo from alioth, but it seems the repo is not configured for fetching over http (which is the only available method for me at work). The proper fix for this would be to configure the repo for dumb http retrievals (see http://wiki.debian.org/Alioth/Git#head-894e0032541f2d8fc1b763b6ee700445608aba63 for more details): chmod a+x $PRJ.git/hooks/post-update # fetches over http work (cd $PRJ.git && git-update-server-info)# fetches over http work For now I grabbed the source package from lenny and applied the patch over that. I am waiting for the thing to compile. > Starting input thread > Creating new input thread > Input thread created > Stopping input thread > Destroying existing input thread > Input thread destroyed > Starting input thread > Creating new input thread > Input thread created > Stopping input thread > Destroying existing input thread > Input thread destroyed > > Daniel > -- Regards, EddyP = "Imagination is more important than knowledge" A.Einstein -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
reassign 479438 cwidget forcemerge 479438 348481 431054 431688 432323 434861 462923 466254 475368 thanks 2009/1/27 Jens Seidel : > On Tue, Jan 27, 2009 at 01:31:34PM +0200, Eddy Petrișor wrote: >> >> suggest that the blocking is not visible when using the 2.6.26 kernel,= >> >> >> while you said that it is. >> > Only two reports? I really doubt it (search for older bugs!). At least it >> > worked for me with a more recent kernel whereas it freezed using 2.6.28 >> >> Did you really mean 2.6.28 (which is just 1 month old), or did you mean >> 2.6.18 (etch's kernel)? > > Ah, no. I mean 2.6.18. OK, that's better (for the localisation of the bug ;-) ). > #462850, #431054 and co are probably all the same to your bug ... Well, the list is a little bit longer (according to the bugs merged with 462850): 348481, 431054, 431688, 432323, 434861, 462923, 466254, 475368 and seems this list misses out latest bugs: 479438, 504063, 511708 Well, now they should be all merged. >> Not sure if other arches than i686-compatible (or the ones in k7's >> generation) are affected, but now that I managed to isolate the version >> that introduced the bug, I guess it will be easier for Daniel to figure >> out the cause of the problem. > > Right. I assumed in the past a problem with the kernel :-) -- Regards, EddyP = "Imagination is more important than knowledge" A.Einstein -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
This is for everyone who can reproduce the bug.
Could you build a libcwidget3 with the attached patch and see what's
produced in /tmp/cwidget.input.log when you reproduce the bug? If I
start aptitude, run dpkg once, and exit, I get this:
Starting input thread
Creating new input thread
Input thread created
Stopping input thread
Destroying existing input thread
Input thread destroyed
Starting input thread
Creating new input thread
Input thread created
Stopping input thread
Destroying existing input thread
Input thread destroyed
Daniel
diff --git a/src/cwidget/toplevel.cc b/src/cwidget/toplevel.cc
index 7cfd048..486fb00 100644
--- a/src/cwidget/toplevel.cc
+++ b/src/cwidget/toplevel.cc
@@ -58,6 +58,8 @@
#include
#include
+#include
+
namespace cwidget
{
std::string version()
@@ -425,22 +427,34 @@ namespace cwidget
public:
static void start()
{
+ std::ofstream out("/tmp/cwidget.input.log", std::ios::app);
+ out << "Starting input thread" << std::endl;
+
threads::mutex::lock l(instance_mutex);
if(instancet == NULL)
- instancet = new threads::thread(threads::make_bootstrap_proxy(&instance));
+ {
+ out << "Creating new input thread" << std::endl;
+ instancet = new threads::thread(threads::make_bootstrap_proxy(&instance));
+ out << "Input thread created" << std::endl;
+ }
}
static void stop()
{
+ std::ofstream out("/tmp/cwidget.input.log", std::ios::app);
+ out << "Stopping input thread" << std::endl;
+
threads::mutex::lock l(instance_mutex);
if(instancet != NULL)
{
+ out << "Destroying existing input thread" << std::endl;
instancet->cancel();
instancet->join();
delete instancet;
instancet = NULL;
+ out << "Input thread destroyed" << std::endl;
}
}
Bug#479438: Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
2009/1/27 Rich Griffiths : > Eddy Petrișor wrote: >> >> >> microwaverich, could you test once more, just to be sure, that under >> each one of these setups aptitude blocks: >> >> 1) etch kernel (2.6.18-6-k7 - if you no longer have it, you can grab >> it from http://packages.debian.org/etch/linux-image-2.6.18-6-k7) >>official aptitude from lenny (0.4.11.11-1~lenny1) >> >> 2) lenny kernel (2.6.26 - >> http://packages.debian.org/lenny/linux-image-2.6.26-1-686) >>official aptitude from lenny (0.4.11.11-1~lenny1) >> >> > > Eddy: > > I still have both kernels installed, so this was easy. Thanks for testing. > I rebooted to 2.6.18-6-k7, switched to console 2, and invoked aptitude. > > In the ncurses aptitude, I searched for xsoldier, hit '+' to select it, and > 'g' twice to install. After completing the install, aptitude did the usual > thing with the cache and looked like it had returned to command mode, but it > was frozen. It would not respond to the keyboard, so I used ctrl-C to kill > it. The keystrokes I had entered while aptitude was frozen were then > waiting there at the root '#' command prompt. As expected. > I rebooted to 2.6.26-1-686 and went through a similar procedure, except I > used '-' to deselect xsoldier. Aptitude worked fine, and exited normally > using 'q', as it has the last few times I've used it. OK, at least we know that the 2.6.26-1-686 kernel is not a good candidate if one wants to catch the bug. > I'm 99% sure (nothing is 100%) that this (behaving properly under the -686 > kernel) is not what was happening when I posted the problem on > linux.debian.user. I keep a written log of everything I do on the machine, > and I noted the freeze-up problem even after switching from the k7 to 686 > kernel. Weird. > But it ain't like that no more! I don't know what has changed. Perhaps I > did make a mistake somewhere along the way. It is possible that maybe something else changed in the environment and the bug is no longer triggered. > I'm happy that the problem is 'fixed' for me. But if I can still be of > help, please feel free to ask. I'm pleased to contribute in any way I can. Thanks, your help is welcome. -- Regards, EddyP = "Imagination is more important than knowledge" A.Einstein -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
Eddy Petrișor wrote: microwaverich, could you test once more, just to be sure, that under each one of these setups aptitude blocks: 1) etch kernel (2.6.18-6-k7 - if you no longer have it, you can grab it from http://packages.debian.org/etch/linux-image-2.6.18-6-k7) official aptitude from lenny (0.4.11.11-1~lenny1) 2) lenny kernel (2.6.26 - http://packages.debian.org/lenny/linux-image-2.6.26-1-686) official aptitude from lenny (0.4.11.11-1~lenny1) Eddy: I still have both kernels installed, so this was easy. I rebooted to 2.6.18-6-k7, switched to console 2, and invoked aptitude. In the ncurses aptitude, I searched for xsoldier, hit '+' to select it, and 'g' twice to install. After completing the install, aptitude did the usual thing with the cache and looked like it had returned to command mode, but it was frozen. It would not respond to the keyboard, so I used ctrl-C to kill it. The keystrokes I had entered while aptitude was frozen were then waiting there at the root '#' command prompt. I rebooted to 2.6.26-1-686 and went through a similar procedure, except I used '-' to deselect xsoldier. Aptitude worked fine, and exited normally using 'q', as it has the last few times I've used it. I'm 99% sure (nothing is 100%) that this (behaving properly under the -686 kernel) is not what was happening when I posted the problem on linux.debian.user. I keep a written log of everything I do on the machine, and I noted the freeze-up problem even after switching from the k7 to 686 kernel. But it ain't like that no more! I don't know what has changed. Perhaps I did make a mistake somewhere along the way. I'm happy that the problem is 'fixed' for me. But if I can still be of help, please feel free to ask. I'm pleased to contribute in any way I can. ... Rich -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
On Tue, Jan 27, 2009 at 01:31:34PM +0200, Eddy Petrișor wrote: > >> suggest that the blocking is not visible when using the 2.6.26 kernel,= > > >> while you said that it is. > > Only two reports? I really doubt it (search for older bugs!). At least it > > worked for me with a more recent kernel whereas it freezed using 2.6.28 > > Did you really mean 2.6.28 (which is just 1 month old), or did you mean > 2.6.18 (etch's kernel)? Ah, no. I mean 2.6.18. #462850, #431054 and co are probably all the same to your bug ... > Not sure if other arches than i686-compatible (or the ones in k7's > generation) are affected, but now that I managed to isolate the version > that introduced the bug, I guess it will be easier for Daniel to figure > out the cause of the problem. Right. I assumed in the past a problem with the kernel :-) > > Wow!!! > > What? The memory usage? Is normal when you compile aptitude in the > background ;-) while having iceweasel opened. 1 GB RAM is maybe more than the sum off all my memory in all computers I own. I probably need more modern hardware :-) Jens -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
>> suggest that the blocking is not visible when using the 2.6.26 kernel,= >> while you said that it is. >=20 > Only two reports? I really doubt it (search for older bugs!). At least = it > worked for me with a more recent kernel whereas it freezed using 2.6.28= =2E Did you really mean 2.6.28 (which is just 1 month old), or did you mean 2.6.18 (etch's kernel)? >> Maybe the common thing is a somewhat slower/older CPU(k7, 686)/machine= ? >> That would somewhat explain the "I see it on SSH, but not on local" re= port from >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D479438#15 . >=20 > Whenever I use aptitude I have to wait up to 5 minutes (or longer) unti= l it > has done it's job but it works. My system is a PIII 800MHz with 256 MB = RAM and > a *very* slow solid state disk. I also tested aptitude on even slower h= ardware > (FreeRunner and a 400MHz Mips workstation and a 370 MHz Mips workstatio= n). It > works well (but slow) on these so I suspect a slow CPU is not related t= o the > problem. Not sure if other arches than i686-compatible (or the ones in k7's generation) are affected, but now that I managed to isolate the version that introduced the bug, I guess it will be easier for Daniel to figure out the cause of the problem. >> If is of any help, this machine has: >> >> 0 e...@twix ~/usr/src/perso/aptitude/aptitude-0.4.11.11 $ free -m >> total used free sharedbuffers cac= hed >> Mem: 1003687315 0 34= 252 >=20 > Wow!!! What? The memory usage? Is normal when you compile aptitude in the background ;-) while having iceweasel opened. --=20 Regards, EddyP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "Imagination is more important than knowledge" A.Einstein signature.asc Description: OpenPGP digital signature
Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
On Mon, Jan 26, 2009 at 05:04:17PM +0200, Eddy Petrișor wrote: > There are 2 reports (1 from myself and another from somebody else) who > suggest that the blocking is not visible when using the 2.6.26 kernel, > while you said that it is. Only two reports? I really doubt it (search for older bugs!). At least it worked for me with a more recent kernel whereas it freezed using 2.6.28. > Maybe the common thing is a somewhat slower/older CPU(k7, 686)/machine? > That would somewhat explain the "I see it on SSH, but not on local" report > from > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479438#15 . Whenever I use aptitude I have to wait up to 5 minutes (or longer) until it has done it's job but it works. My system is a PIII 800MHz with 256 MB RAM and a *very* slow solid state disk. I also tested aptitude on even slower hardware (FreeRunner and a 400MHz Mips workstation and a 370 MHz Mips workstation). It works well (but slow) on these so I suspect a slow CPU is not related to the problem. > If is of any help, this machine has: > > 0 e...@twix ~/usr/src/perso/aptitude/aptitude-0.4.11.11 $ free -m > total used free sharedbuffers cached > Mem: 1003687315 0 34252 Wow!!! Jens -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
(microwavwrich, please see somewhere below some paragraphs addressed to you. Thanks in advance.) 2009/1/21 Daniel Burrows : > On Tue, Jan 20, 2009 at 03:45:37PM +0200, Eddy Petrișor > was heard to say: >> I think I have found a lead after reading a comment from another user: >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504063#17 >> >> >> I installed lenny's kernel and with this kernel the bug is no longer visible >> with the new version. > > Unfortunately, this is not true everywhere: e.g., "microwaverich" can > reproduce the bug under 2.6.26-1-686. I had to google for it, but I found the thread on -user and read it. I am still inclined to believe that maybe some confusion settled in during the debug phase for microweverich, because everybody makes mistakes and there's another user reporting that under 2.6.26 the bug is not visible, just like myself. microwaverich, could you test once more, just to be sure, that under each one of these setups aptitude blocks: 1) etch kernel (2.6.18-6-k7 - if you no longer have it, you can grab it from http://packages.debian.org/etch/linux-image-2.6.18-6-k7) official aptitude from lenny (0.4.11.11-1~lenny1) 2) lenny kernel (2.6.26 - http://packages.debian.org/lenny/linux-image-2.6.26-1-686) official aptitude from lenny (0.4.11.11-1~lenny1) There are 2 reports (1 from myself and another from somebody else) who suggest that the blocking is not visible when using the 2.6.26 kernel, while you said that it is. Please don't take this the wrong way, I am just trying to help to identify the origin of this bug, I am in NO way saying or suggesting something else. > Another question: if you download the aptitude source and run > "./configure && make" (after installing its build-deps, of course), do > you get the bug when you run "./src/aptitude"? I have at least one > report that just recompiling the current source makes the bug "go away". No it didn't make it go away, but please note that I tried the official lenny source, not the hg tracked one. > I doubt that's the fix; just more evidence that there's something very > timing-dependent or perhaps memory-layout-dependent going on (the thing > I don't see is why it's only reproducible on a few machines with > particular builds, but reproducible 100% of the time under those > circumstances). Maybe the common thing is a somewhat slower/older CPU(k7, 686)/machine? That would somewhat explain the "I see it on SSH, but not on local" report from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479438#15 . If is of any help, this machine has: 0 e...@twix ~/usr/src/perso/aptitude/aptitude-0.4.11.11 $ free -m total used free sharedbuffers cached Mem: 1003687315 0 34252 -/+ buffers/cache:400602 Swap: 964 0964 0 e...@twix ~/usr/src/perso/aptitude/aptitude-0.4.11.11 $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping: 9 cpu MHz : 2793.059 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr bogomips: 5591.68 clflush size: 64 power management: processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.80GHz stepping: 9 cpu MHz : 2793.059 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 1 apicid : 1 initial apicid : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr bogomips: 5586.29 clflush size: 64 power management: I'll try to hg bisect in the background while doing my work and see if I can spot the problematic commit. -- Regards, EddyP = "Imagination is more important than knowledge" A.Einstein -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#504063: Bug#511708: aptitude: [etch upgrade] TUI consistently blocks after doing one set of operations
On Tue, Jan 20, 2009 at 03:45:37PM +0200, Eddy Petrișor was heard to say: > I think I have found a lead after reading a comment from another user: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504063#17 > > > I installed lenny's kernel and with this kernel the bug is no longer visible > with the new version. Unfortunately, this is not true everywhere: e.g., "microwaverich" can reproduce the bug under 2.6.26-1-686. Another question: if you download the aptitude source and run "./configure && make" (after installing its build-deps, of course), do you get the bug when you run "./src/aptitude"? I have at least one report that just recompiling the current source makes the bug "go away". I doubt that's the fix; just more evidence that there's something very timing-dependent or perhaps memory-layout-dependent going on (the thing I don't see is why it's only reproducible on a few machines with particular builds, but reproducible 100% of the time under those circumstances). Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
