Re: [maemo-developers] how to start dropbear server
On Thursday 14 September 2006 15:34, Marius Gedminas wrote: > On Thu, Sep 14, 2006 at 08:49:05AM +0200, Antonio Orlando wrote: > > Ok much thanks; summying up: > > > > * after installing "dropbear_0.48-0.1_armel.deb" it starts automatically > > > > * to stop the server: (only way?) kill process > > There should be a script in /etc/init.d/ > > /etc/init.d/dropbear stop > > > * to restart the server: (only way?) reboot device > > /etc/init.d/dropbear start > > > * packages ending with _arm are (always?) for IT2005 > > Or the current Debian ARM port. > > > * packages ending with _armel are (always?) for IT2006 > > Or the upcoming Debian ARM port. > > > * http://maemo.org/maemowiki/InstallSsh: maybe this page should at least > > include somewhere that it is written for IT2005 > > Marius Gedminas Installing and starting dropbear is usually not a big problem, being able to connect to it is a different story. It does not work for me if I just connect to the WLAN connection. I have to open a browser window for example in order for the connection to get "activated". Only after this I can ssh Also sometimes the ssh connections freeze up. I have to disconnect from the WLAN, then re-connect and open a browser window again in order to "unfreeze" my existing SSH connections or establish new ones. Is there any way around this? cheers, Christian Henz ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] SDK vs. device: libSM and libICE
On Tuesday 29 August 2006 14:50, you wrote: > Cristian, > > have a look at this > http://maemo.org/pipermail/maemo-developers/2006-July/004489.html > My point is that the libs are only in the maemo repository. They are not on the device or the catalogue.tableteer.nokia.com repository. I do not want to install them on the device since I don't even need them. They are just linked because they are found on the SDK. And you can not uninstall them in the SDK because xlibs-dev depends on them. cheers, Christian Henz ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] SDK vs. device: libSM and libICE
I might be missing something, but I think this is a bug in the SDK: In the SDK, libSM and libICE are available, while on the device, they are not. For example VLC's configure.ac script uses AC_PATH_XTRA() from /usr/share/autoconf/autoconf/libs.m4, which correctly finds libSM and libICE in the SDK and adds them to the libs to link to the x11 plugin. On the device of course the x11 plugin will then fail to load because the libs cannot be found. I think the libs should be removed from the SDK (or at least be made removable). For that to happen, some dependencies would have to be resolved, ie xlibs-dev. cheers, Christian Henz ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problem with GDB and threads...
On Tuesday 18 July 2006 19:35, Christian Henz wrote:
>
> The compilation of glibc did not explicitly use "-fomit-frame-pointer", but
> the GCC manual states that "-O" implies it on architectures where it
> doesn't break debugging. Unfortunately it doesn't mention which
> architectures those are. I'm currently recompiling glibc with explicitly
> setting
> "-fno-omit-frame-pointer".
>
This finally did the trick. I configured and compiled glibc using
./configure [...] CFLAGS="-g -O2 -fno-omit-frame-pointer"
Now the backtrace doesn't repeat forever, although I still get "Previous frame
identical to this frame (corrupt stack?)".
# gdb ./testc-armel
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi"...Using host libthread_db
library "/usr/lib/debug/libthread_db.so.1".
(gdb) break test.c:26
Breakpoint 1 at 0x84f4: file test.c, line 26.
(gdb) run
Starting program: /mnt/nessie/nokia770/testc-armel
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 1127)]
BFD: /usr/lib/debug/lib/ld-2.3.6.so: warning: sh_link not set for section
`.ARM.exidx'
[New Thread 32769 (LWP 1130)]
[New Thread 16386 (LWP 1131)]
[Switching to Thread 16384 (LWP 1127)]
Breakpoint 1, main (argc=1, argv=0xbe8e2744) at test.c:26
26 test.c: No such file or directory.
in test.c
(gdb) thread apply all bt
Thread 3 (Thread 16386 (LWP 1131)):
#0 0x40115a84 in sched_yield () at regex_internal.c:71
#1 0x40029af8 in __pthread_acquire (spinlock=0x40037d1c) at spinlock.c:711
#2 0x40024c90 in pthread_start_thread_event (arg=0xbe1ffbe0) at manager.c:329
#3 0x4012ae10 in clone () from /usr/lib/debug/libc.so.6
#4 0x4012ae10 in clone () from /usr/lib/debug/libc.so.6
Previous frame identical to this frame (corrupt stack?)
Thread 2 (Thread 32769 (LWP 1130)):
#0 0x40121f08 in *__GI___poll (fds=0x13000, nfds=1, timeout=2000)
at ../sysdeps/unix/sysv/linux/poll.c:86
#1 0x4002520c in __pthread_manager (arg=0xfffc) at manager.c:152
#2 0x40025a88 in __pthread_manager_event (arg=0x46b) at manager.c:249
#3 0x4012ae10 in clone () from /usr/lib/debug/libc.so.6
#4 0x4012ae10 in clone () from /usr/lib/debug/libc.so.6
Previous frame identical to this frame (corrupt stack?)
Thread 1 (Thread 16384 (LWP 1127)):
#0 main (argc=1, argv=0xbe8e2744) at test.c:26
(gdb)
cheers,
Christian Henz
#include
#include
#include
void* routine( void* arg ) {
int i = 0;
while( i < 15 ) {
sleep( 1 );
i++;
}
return 0;
}
int main( int argc, char** argv ) {
pthread_t handle;
void* retval;
int err = pthread_create( &handle, 0, routine, 0 );
assert( err == 0 );
err = pthread_join( handle, &retval );
assert( err == 0 );
return 0;
}
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problem with GDB and threads...
On Tuesday 18 July 2006 15:23, Eero Tamminen wrote: > Hi, > > > I simply compiled with "-g" before, adding the "-no-omit-frame-pointer" > > directive did not help. > > Actually I think the library where the function giving infinite > backtrace is should be compiled with -g (or debug package for > it should be installed). If that doesn't help then you need > to compile that library / binary with -fno-omit-frame-pointer. > Since I could not find a binary libc6-dbg package, I compiled it myself from the package source. But it still does not work: # gdb ./testc-armel GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "arm-linux-gnueabi"...Using host libthread_db library "/usr/lib/debug/libthread_db.so.1". (gdb) r Starting program: /mnt/nessie/nokia770/testc-armel [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 1146)] BFD: /usr/lib/debug/lib/ld-2.3.6.so: warning: sh_link not set for section `.ARM.exidx' [New Thread 32769 (LWP 1149)] [New Thread 16386 (LWP 1150)] Program received signal SIGINT, Interrupt. [Switching to Thread 16386 (LWP 1150)] 0x400f937c in nanosleep () at stdlib.h:338 338 stdlib.h: No such file or directory. in stdlib.h (gdb) thread apply all bt Thread 3 (Thread 16386 (LWP 1150)): #0 0x400f937c in nanosleep () at stdlib.h:338 #1 0x400f9164 in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:138 #2 0x8488 in routine (arg=0x0) at test.c:11 #3 0x40024a20 in pthread_start_thread (arg=0xfdfc) at manager.c:310 #4 0x40024a20 in pthread_start_thread (arg=0xfdfc) at manager.c:310 #5 0x40024a20 in pthread_start_thread (arg=0xfdfc) at manager.c:310 #6 0x40024a20 in pthread_start_thread (arg=0xfdfc) at manager.c:310 #7 0x40024a20 in pthread_start_thread (arg=0xfdfc) at manager.c:310 #8 0x40024a20 in pthread_start_thread (arg=0xfdfc) at manager.c:310 #9 0x40024a20 in pthread_start_thread (arg=0xfdfc) at manager.c:310 #10 0x40024a20 in pthread_start_thread (arg=0xfdfc) at manager.c:310 #11 0x40024a20 in pthread_start_thread (arg=0xfdfc) at manager.c:310 [...] > At least one reason for the infinite backtraces has been __attribute__ > ((__noreturn__)) specified to functions. That is given to functions > that do not return and for them -fno-omit-frame-pointer is needed to > get working backtrace, for them -g is not enough. Normally those are > exit functions, but maybe thread creation function doesn't return > either? (I've seen some thread usage example code where __noreturn__ > attribute is used for them) > The compilation of glibc did not explicitly use "-fomit-frame-pointer", but the GCC manual states that "-O" implies it on architectures where it doesn't break debugging. Unfortunately it doesn't mention which architectures those are. I'm currently recompiling glibc with explicitly setting "-fno-omit-frame-pointer". Thanks so far :-) Christian ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Developing directly on the 770
On Tuesday 18 July 2006 15:54, Thanos Panousis wrote: > Hello list, > > I would like to ask the list for a general developing question. I need to > set up some kind of shared directory between the 770 and my developing PC. > This way I can write a python script on my PC editor, save on the shared > directory directly which would lie on the 770, and then just run the script > through ssh from my pc as well. > > This way I dont have to use the SDK, the stuff I need to do are simple so > using it just makes my life harder. > > I accomplished this already using sshfs. The thing is that sshfs just > decided to stop working, when I issue the mount command, it asks for the > remote ssh password of the 770 and then just hangs... no output whatsoever, > just stays there. > > What other alternatives have you ppl been using? I use NFS, but with the 2006 OS you have to re-compile the kernel for that. cheers, Christian Henz ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problem with GDB and threads...
On Friday 14 July 2006 08:37, Eero Tamminen wrote: > Hi, > > > On the Nokia 770, the backtrace goes on forever and i have to kill gdb > > Have you compiled your binary: > - without optimization (or used -no-omit-frame-pointer) > - with -g > - not stripped it > ? > > If not, if you do that and try again, does the debugging work better? > I simply compiled with "-g" before, adding the "-no-omit-frame-pointer" directive did not help. > If it still doesn't work, does it work if you install 'libc6-dbg' > package and run your program, or GDB starting your program, with: > LD_LIBRARY_PATH=/usr/lib/debug:$LD_LIBRARY_PATH gdb /path/app > ? > I can't seem to find that package in the mistral repositories. cheers, Christian Henz ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Problem with GDB and threads...
Hi.
I have a problem when trying to debug a multi-threaded application on the
Nokia 770 (OS 2006).
This is my test program:
#include
#include
#include
void* routine( void* arg ) {
while( 1 ) { }
return 0;
}
int main( int argc, char** argv ) {
pthread_t handle;
int err = pthread_create( &handle, 0, routine, 0 );
assert( err == 0 );
sleep( 60 );
return 0;
}
On the PC, I do the following in gdb:
(gdb) inf thr
2 Thread -1479910480 (LWP 29458) routine (arg=0x0) at test.cpp:8
* 1 Thread -1479907648 (LWP 29455) 0xa7d3a2bc in nanosleep ()
from /lib/tls/libc.so.6
(gdb) thread apply all bt
Thread 2 (Thread -1479910480 (LWP 29458)):
#0 routine (arg=0x0) at test.cpp:8
#1 0xa7ef7ced in start_thread () from /lib/tls/libpthread.so.0
#2 0xa7d79dee in clone () from /lib/tls/libc.so.6
Thread 1 (Thread -1479907648 (LWP 29455)):
#0 0xa7d3a2bc in nanosleep () from /lib/tls/libc.so.6
#1 0xa7d3a0c4 in sleep () from /lib/tls/libc.so.6
#2 0x08048562 in main (argc=1, argv=0xafa2c274) at test.cpp:22
On the Nokia 770, the backtrace goes on forever and i have to kill
gdb:
(gdb) inf thr
3 Thread 16386 (LWP 2269) 0x84b0 in routine ()
2 Thread 32769 (LWP 2268) 0x402a3474 in poll () from /lib/libc.so.6
* 1 Thread 16384 (LWP 2265) 0x4027e37c in nanosleep () from /lib/libc.so.6
(gdb) thread apply all bt
Thread 3 (Thread 16386 (LWP 2269)):
#0 0x84b0 in routine ()
#1 0x40024a20 in pthread_start_thread () from /lib/libpthread.so.0
#2 0x40024a20 in pthread_start_thread () from /lib/libpthread.so.0
#3 0x40024a20 in pthread_start_thread () from /lib/libpthread.so.0
#4 0x40024a20 in pthread_start_thread () from /lib/libpthread.so.0
#5 0x40024a20 in pthread_start_thread () from /lib/libpthread.so.0
#6 0x40024a20 in pthread_start_thread () from /lib/libpthread.so.0
[...]
Has anyone else experienced this? Also, why is there an extra thread?
thanks,
Christian Henz
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Kernel 2.6.16 menuconfig...
... does not work for me because ncurses does not get linked. The linker flags are created in kernel-source-2.6.16/scripts/kconfig/lxdialog/check-lxdialog.sh The script tries to find the right lib to link by calling "gcc -print-file-name=...". On my Debian/testing host this works, but in my Scratchbox/Maemo2b enviroment these tests come up emtpy. ncurses IS installed though, since I can link it manually and also menuconfig works for kernel 2.6.12. In fact I got 2.6.16 menuconfig to work by just shortcutting the test in the script to echoing "-lncurses". It was suggested here (http://www.ussg.iu.edu/hypermail/linux/kernel/0604.0/0050.html) that the problem might be due to wrong symlinks, but they looked okay to me (ie exactly as on the Debian host except for the "w" variants). cheers, Christian ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
