From: Paul F. <pf...@ta...> - 2003-09-16 11:52:30
|
Hello all, First I've noticed a couple of things with UML. I've put them at the end of this email. Anyway, I'm trying to run a multithreaded program on a UML node. The program functions correctly when run normally from the shell prompt. However when run inside GDB the following happens: 1) My program calls pthread_create() 2) Signal SIG32 is received and debugging stops: Program received signal SIG32, Real-time event 32. 0x40068469 in sigsuspend () from /lib/libc.so.6 3) Program stack trace is: my_function() -> pthread_create() -> pthread_getconcurrency() -> sigsuspend() Are there any known issues with UML, GDB, multithreaded applications and signals? I've tried my program with 2.4.19-5um and 2.4.22-4um. In both cases with the Tracing Thread style of operation. Would SKAS mode make any difference? Hopefully someone can shed some light on my problem. Thanks in advance, Paul Fee Here are the other things I've noticed: ======================================================================= 1) Kernel 2.4.22-4 and uml-patch-2.4.22-4.bz2 will not build with the default kernel configuration. I get an error with file mem.c: mem.c: In function `memory_devfs_register': mem.c:724: `anon_fops' undeclared (first use in this function) mem.c:724: (Each undeclared identifier is reported only once mem.c:724: for each function it appears in.) mem.c:724: initializer element is not constant mem.c:724: (near initialization for `list[8].fops') mem.c:724: initializer element is not constant mem.c:724: (near initialization for `list[8]') I've got round this by running "make xconfig ARCH=um" and enabling "Anonymous memory" in the "Character devices" section. ======================================================================= 2) I've seen an endian or network/host byte order funny with ping's route record option. Here's the output, the host has a tuntap interface of 192.168.2.1, the UML node has eth0 configured as 192.168.2.2 Host output: >ping -R 192.168.2.2 PING 192.168.2.2 (192.168.2.2) from 192.168.2.1 : 56(124) bytes of data. 64 bytes from 192.168.2.2: icmp_seq=1 ttl=64 time=0.389 ms RR: 192.168.2.1 192.168.2.2 192.168.2.2 192.168.2.1 --- 192.168.2.2 ping statistics --- 3 packets transmitted, 3 received, 0% loss, time 2003ms rtt min/avg/max/mdev = 0.348/0.366/0.389/0.023 ms UML output: # ping -R 192.168.2.1 PING 192.168.2.1 (192.168.2.1): 56 octets data 64 octets from 192.168.2.1: icmp_seq=0 ttl=64 time=0.7 ms RR: 2.2.168.192 1.2.168.192 1.2.168.192 2.2.168.192 ======================================================================== |
From: Paul F. <pf...@ta...> - 2003-09-16 16:40:17
|
Stefan Nitz wrote: > Dear listeners, > > sorry, I'm to stupid to compile successfully the UML. This is my result: > > gcc -D__KERNEL__ -I/usr/local/src/uml/linux-2.4.22/include -Wall >-Wstrict-prototypes >-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -U__i386__ -Ui386 >-DUM_FASTCALL -g >-D__arch_um__ -DSUBARCH="i386" -D_LARGEFILE64_SOURCE >-I/usr/local/src/uml/linux-2.4.22/arch/um/include -Derrno=kernel_errno >-I/usr/local/src/uml/linux-2.4.22/arch/um/kernel/tt/include >-I/usr/local/src/uml/linux-2.4.22/arch/um/kernel/skas/include >-nostdinc -iwithprefix >include -DKBUILD_BASENAME=mem -c -o mem.o mem.c > mem.c: In function `memory_devfs_register': > mem.c:724: `anon_fops' undeclared (first use in this function) [SNIP] Try running: > make xconfig ARCH=um Go to the "Character devices" section Change "Anonymous memory" to yes. Then give the build another go: > make linux ARCH=um -- Paul Fee |
From: Patrick \Petschge\ K. <pet...@we...> - 2003-09-16 22:14:12
|
Hi, Paul Fee wrote: > 2) I've seen an endian or network/host byte order funny with ping's > route record option. Here's the output, the host has a tuntap interface > of 192.168.2.1, the UML node has eth0 configured as 192.168.2.2 [snip] I'm not able to reproduce this. Which kernel versions do you use on the host and as uml? mfg, Patrick "Petschge" Kilian -- "If certain acts of violation of treaties are crimes, they are crimes whether the United States does them or whether Germany does them, and we are not prepared to lay down a rule of criminal conduct against others which we would not be willing to have invoked against us." -- Robert Jackson, American prosecutor in the Nuremberg War-Crimes Trial |
From: Paul F. <pf...@ta...> - 2003-09-17 10:04:11
|
I've seen this behaviour with: Host: 2.4.19 Host distro: SuSE 8.1 Ping version: ping utility, iputils-ss020124 UML: 2.4.19-5um and 2.4.22-4um Patrick "Petschge" Kilian wrote: > Hi, > > Paul Fee wrote: > >>2) I've seen an endian or network/host byte order funny with ping's >>route record option. Here's the output, the host has a tuntap interface >>of 192.168.2.1, the UML node has eth0 configured as 192.168.2.2 > > [snip] > I'm not able to reproduce this. Which kernel versions do you use on the host > and as uml? > > mfg, > Patrick "Petschge" Kilian > > |
From: Paul F. <pf...@ta...> - 2003-09-17 12:49:34
|
I've done another experiment. I've used the text ethereal program (tethereal) to capture packets on both the host and the uml node. I've looked in the Record Record fields of the IP packet. On both the host and the uml node the IP addresses are recorded correctly. This tells me that the packets are correctly formatted by UML and also correctly interrupted by tethereal (running on both UML and host). However when it comes to displaying the Route Record information the UML ping program displays it incorrectly. ... oh ... hold on ... Ah - The version of ping in the root_fs_slack8.1.bz2 root filesystem is at fault. When I copy that version of ping to the host it continues to malfunction. So the answer is the Slackware 8.1 ping program was at fault. UML is functioning correctly. Sorry for the red herring. -- Paul Patrick Kilian wrote: > Hi, > > >>I've seen this behaviour with: >> >>Host: 2.4.19 >>Host distro: SuSE 8.1 >>Ping version: ping utility, iputils-ss020124 >> >>UML: 2.4.19-5um and 2.4.22-4um > > > I can't reproduce this with: > Host: 2.4.18 (as shipped with SuSE 8.0) > Host distro: SuSE 8.0 > Ping version: iputils-ss020124 > > UML: 2.4.19-51um, 2.4.20-6um, 2.4.21-6um and 2.6.0-test5-1um > > mfg, > Patrick "Petschge" Kilian > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > |
From: Patrick K. <pet...@gm...> - 2003-09-17 16:48:37
|
Hi, > Ah - The version of ping in the root_fs_slack8.1.bz2 root filesystem > is at fault. Is someone able to reproduce the error with this filesystem? Perhaps the=20 fs image is broken. In this case it should be fixed. Or is the ping=20 shipped with Slackware 8.1 broken? Perhaps someone should send a=20 bugrepport to Slackware in this case. > So the answer is the Slackware 8.1 ping program was at fault. UML is > functioning correctly. Sorry for the red herring. No harm done. It is better to find one bug that isn't real than to miss=20 a real bug;-) mfg, Patrick "Petschge" Kilian --=20 Erst wenn der letzte FTP Server kostenpflichtig, der letzte GNU-Sourcecode verkauft, der letzte Algorithmus patentiert, der letzte Netzknoten kommerzialisiert, die letzte Newsgroup moderiert wird, werdet Ihr merken, dass man mit Geld allein nicht programmieren kann. |
From: Jeff D. <jd...@ad...> - 2003-09-17 22:18:18
|
pf...@ta... said: > 1) My program calls pthread_create() > 2) Signal SIG32 is received and debugging stops: > Program received signal SIG32, Real-time event 32. > 0x40068469 in sigsuspend () from /lib/libc.so.6 > 3) Program stack trace is: > my_function() -> pthread_create() -> pthread_getconcurrency() -> > sigsuspend() Is this different behavior from the host? pthreads does use SIGRT* to communicate between threads, I believe, and gdb is well within its rights to report that to you. Jeff |
From: Paul F. <pf...@ta...> - 2003-09-18 09:08:28
|
Jeff, Yes the behaviour is different from the host. However looking at the signal handling (with the DDD front end). I've notice that on the host the SIG32 signal (Real-time event 32) is neither "stopped" nor "printed". Changing the signal handling on the UML node to match the host fixes my problem, allowing my program to create threads. I am noticing that running DDD on the host and GDB on the UML node is a bit slow and unreliable (lose DDD->GDB connection), but I'm not sure which component to blame (DDD, GDB, UML)? > ddd --host <user>@<host> <program> Now I'll have to find where the default signal handling behaviour is stored - most likely DDD or GDB preferences. Perhaps the GDB preferences are different in the Slackware 8.1 filesystem that I'm using for UML. Thanks for you help, Paul Jeff Dike wrote: > pf...@ta... said: > >>1) My program calls pthread_create() >>2) Signal SIG32 is received and debugging stops: >>Program received signal SIG32, Real-time event 32. >>0x40068469 in sigsuspend () from /lib/libc.so.6 >>3) Program stack trace is: >>my_function() -> pthread_create() -> pthread_getconcurrency() -> >>sigsuspend() > > > Is this different behavior from the host? pthreads does use SIGRT* to > communicate between threads, I believe, and gdb is well within its rights > to report that to you. > > Jeff > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > |
From: Jeff D. <jd...@ad...> - 2003-09-23 20:24:32
|
pf...@ta... said: > Now I'll have to find where the default signal handling behaviour is > stored - most likely DDD or GDB preferences. Perhaps the GDB > preferences are different in the Slackware 8.1 filesystem that I'm > using for UML. Yeah, that's what I'm thinking. This doesn't look like a difference in kernel behavior. Jeff |