前天晚上在京东买了一台电脑，昨天傍晚送到，花了一晚上的功夫才把它装好。
早上起来开始装操作系统，没想到openSUSE 11的光盘插进去，选择Install，然后在加载Kernel的第一步就死掉了。选择文本的安装模式一看，提提示 BUG Int 14 : CR2 ffb41000。
上网查了一下，14号中断原来是给换页错误用的。首先被怀疑的就是4G内存。回到BIOS关闭Memory remap，问题依旧。
用Google搜索了一下英文的内容，发现有人和我有同样的问题，而且还是同样的主板：ASUS P5QL-PRO。看下去，原来这是Linux Kernel的一个bug。如果某块数据在某页第一个字节结束的情况下，Linux错误的把页卸载了。恰好，ASUS P5QL-PRO的DMI表就满足这个情况。
打电话给ASUS的技术支持，询问是否有办法调整这一问题，没想到差点被雷死。她说：“P5QL是一款家用型的主板，华硕家用型的主板都是按Windows平台设计的。”
这下晕了，还好，似乎只有2.6.26的核受到影响，我还有得用。
Post by : cooper
Post under : Writing, bug, linux, P5QL-PRO, 华硕
on October 30th, 2008 | 1 Comment »
这两天Firefox出现了一系列问题，刚才终于找到了罪魁祸首AideRSS Google Reader Integration。它会导致：
- Greasemonkey的管理窗口无法打开。
- Firefox退出后进程不会结束。
Post by : cooper
Post under : Coding, bug, firefox, 扩展
on September 5th, 2008 | No Comments »
有人报告了gcc一个奇怪的行为，这样的一段代码居然能够通过编译。
#include <cstdio>
#define NUM getnum()
int getnum()
{
int x = 0;
scanf("%d", &x);
printf("%d\n", x);
return x;
}
int main()
{
int array[NUM];
printf("array size =%d\n",sizeof(array));
return 0;
}
要命的是，编译之后居然还能运行。sizeof可以是运行期间确定的吗？
为了确定问题所在，我用-E选项对源代码进行预处理展开，对展开的代码再重新进行编译，居然还是通过了。这意味着问题根本不是由于那个宏引起的。于是，这样的代码也就通过了编译。
#include <cstdio>
int getnum()
{
int x = 0;
scanf("%d", &x);
printf("%d\n", x);
return x;
}
int main()
{
int array[getnum()];
printf("array size =%d\n",sizeof(array));
return 0;
}
本来sizeof应该是编译期间常数，居然现在连运行期间常数都不是了。不知道gcc做了什么样的优化导致了这个问题。如果再把template参数掺和进来，岂不是会更有意思？
有地方说在C99以后，数组有两种定义：一种是大小是编译期间常数的，另外一种则不是。区别在于，前者分配在stack上，后者分配在heap上。并且在两者上执行sizeof也有不同的效果。
Post by : cooper
Post under : Coding, bug, gcc
on August 13th, 2008 | No Comments »
