g***l
发帖数: 2753 | 1 今天是别的组写的一个程序，一跑起来就有“Unable to handle kernel paging
request at virtual address 0xdeadbeef”.
这个问题就很棘手了，不知道是kernal的那个模块出问题了。
如果是user space的程序/库出了问题，会引起这个问题吗？谢谢。 |
t****t
发帖数: 6806 | 2 "0xdeadbeef"? 你就是拿这个代替一下还是真是这个地址?
【在 g***l 的大作中提到】
: 今天是别的组写的一个程序，一跑起来就有“Unable to handle kernel paging
: request at virtual address 0xdeadbeef”.
: 这个问题就很棘手了，不知道是kernal的那个模块出问题了。
: 如果是user space的程序/库出了问题，会引起这个问题吗？谢谢。
|
g***l
发帖数: 2753 | 3 就是代替一下而已。
【在 t****t 的大作中提到】
: "0xdeadbeef"? 你就是拿这个代替一下还是真是这个地址?
|
m*****e
发帖数: 4193 | 4
It's a kernel bug.
【在 g***l 的大作中提到】
: 今天是别的组写的一个程序，一跑起来就有“Unable to handle kernel paging
: request at virtual address 0xdeadbeef”.
: 这个问题就很棘手了，不知道是kernal的那个模块出问题了。
: 如果是user space的程序/库出了问题，会引起这个问题吗？谢谢。
|
g***l
发帖数: 2753 | 5 那就是说不是由于user space的程序/库引起来的了？
谢谢
【在 m*****e 的大作中提到】
:
: It's a kernel bug.
|
m*****e
发帖数: 4193 | 6 It's triggered by the user space, but it's a kernel bug to oops.
【在 g***l 的大作中提到】
: 那就是说不是由于user space的程序/库引起来的了？
: 谢谢
|
y***d
发帖数: 2330 | 7 这个程序干什么了？就是计算还是跟硬件交互？
【在 g***l 的大作中提到】
: 今天是别的组写的一个程序，一跑起来就有“Unable to handle kernel paging
: request at virtual address 0xdeadbeef”.
: 这个问题就很棘手了，不知道是kernal的那个模块出问题了。
: 如果是user space的程序/库出了问题，会引起这个问题吗？谢谢。
|
g***l
发帖数: 2753 | 8 嵌入式系统，需要跟硬件交互，估计是directFB引起来的。
【在 y***d 的大作中提到】
: 这个程序干什么了？就是计算还是跟硬件交互？
|
y***d
发帖数: 2330 | 9 随便搜了一下，说可能内核/用户地址转换没搞对... 或者，比如你这个程序往硬件地
址写东西，结果写错地儿了?
【在 g***l 的大作中提到】
: 嵌入式系统，需要跟硬件交互，估计是directFB引起来的。
|
x****u
发帖数: 44466 | 10 用户态程序写不了硬件地址，要写也是驱动帮忙。
【在 y***d 的大作中提到】
: 随便搜了一下，说可能内核/用户地址转换没搞对... 或者，比如你这个程序往硬件地
: 址写东西，结果写错地儿了?
|
|
|
n*****n
发帖数: 5277 | |
h**i
发帖数: 712 | 12 应该是driver的bug
【在 g***l 的大作中提到】
: 嵌入式系统，需要跟硬件交互，估计是directFB引起来的。
|
g***l
发帖数: 2753 | 13 今天发现问题奇怪的解决了。把用户程序中的一个线程的stack size从4K增加到32K，
就没有这个kernal oops。但是从log中，从来没有什么stack overflow的信息啊。
对了，这个stack overflow都是怎样来检测的？
【在 h**i 的大作中提到】
: 应该是driver的bug
|
h**i
发帖数: 712 | 14 用户的stack overflow不会导致kernel oops,除非你用了上千thread，而且申请了过多
的虚拟内存，但是现在你只有32k。
gcc 有 -fstack-check 选项，可以测试stack overflow，或者用gdb和backtrace().
glibc 缺省在stack之间用一个保护页，函数 pthread_attr_setguardsize可以帮你调
试是不是stack miss the guard page.
【在 g***l 的大作中提到】
: 今天发现问题奇怪的解决了。把用户程序中的一个线程的stack size从4K增加到32K，
: 就没有这个kernal oops。但是从log中，从来没有什么stack overflow的信息啊。
: 对了，这个stack overflow都是怎样来检测的？
|
g***l
发帖数: 2753 | 15 有可能是stack overflow以后，stack上的变量的值被改成了一个不可访问的地址。但
是这种情况下，user space下的程序应该有segmentation fault才对。
【在 h**i 的大作中提到】
: 用户的stack overflow不会导致kernel oops,除非你用了上千thread，而且申请了过多
: 的虚拟内存，但是现在你只有32k。
: gcc 有 -fstack-check 选项，可以测试stack overflow，或者用gdb和backtrace().
: glibc 缺省在stack之间用一个保护页，函数 pthread_attr_setguardsize可以帮你调
: 试是不是stack miss the guard page.
|
