DSM-G600, DNS-3xx and NSA-220 Hack Forum

ruifung wrote:

I just flashed Alt-F on my DNS-323 C1, its working great! Now I am wondering whether its possible to run twonkyserver with Alt-F as I am enountering a "cannot resolve symbol 'atexit'" error when attempting to start twonky.

So it looks like 'atexit' is not available under the uclibc or gcc that Alt-F is built-on.

In September I can try to reconfigure the toolchain, in order to include/provide 'atexit', but not before.
Is that one the only error?

Have you installed ffp? Do you know how to specify a LD_LIBRARY_PATH to ffp libs?

I will not have access to my box in the next months, and only very limited internet access, so I cant help any further.
Someone else can?

Last edited by jcard (2011-06-30 23:50:24)

I have this problem too, I'm not a linux expect, but I tried rebuilding Alt-F with the support for old style atexit, and used LD_LIBRARY_PATH to the old libraries. This fixes the atexit problem and looks like it starts up ok, but then it crashes out and keeps restarting.  I'm not sure where, need to build the libraries in debug and try and use gdb.  This can be reproduced with the try version of twonky server, even if the try out period has passed.

I can't remember now what I did, it was a couple of months ago, will have a look when I can.  I managed to do the LD_LIBARY_PATH to the /ffp/lib and also to the original firmware 1.10 library files which I copied.

ldd twonkymedia
        libpthread.so.0 => /lib/libpthread.so.0 (0x4000d000)
        libc.so.0 => /lib/libc.so.0 (0x40026000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40000000)

The result doesn't change when I do LD_LIBRARY_PATH or not, but with the LD_LIBRARY_PATH pointing to the original firmware library it gets pass the atexit problem and get IllegalInstruction when running the twonkymediaserver exec. the ffp libraries still get the can't find atexit problem.  So it could be picking up half the libraries but not the other half.  if I just run vi with the LD_LIBRARY_PATH set then this gets an Illegal Instruction as well.

LD_RUN_PATH doesn't make any difference.

objdump didn't seem to show any fixed paths.

The other versions seems to do the same, I'll update to the latest AltF and do a build.

Last edited by maddas (2011-07-19 12:39:09)

I was not also successful.

-LD_LIBRARY_PATH does not seems to work on uclibc, but it does,  is 'ldd' that does not shows the correct path:
  -when using LD_LIBRARY_PATH to point to the /ffp/lib, twonky populates the twonky data subdirectory and creates a logfile but end-up complaining with the missing 'atexit()'
  -when using LD_LIBRARY_PATH to point to the "new" Alt-F libs, it does not complain about 'atexit' but does not populates the data subdir and does not creates a log file.

-in the last case above, using 'strace -o /tmp/strace.out  -f -F' to trace both twonkymedia and its child process twonlymediaserver (that keeps dying and being relaunched) shows a segmentation fault:

2167  execve("/mnt/sda2/ffp/opt/twonky/twonkymedia", ["/mnt/sda2/ffp/opt/twonky /twonkym"...], [/* 7 vars */]) = 0
...
2167  fork()                            = 2168
2167  exit(0)                           = ?
2168  getpid()                          = 2168
2168  unlink("/var/run/mediaserver.pid") = -1 ENOENT (No such file or directory)
...
2168  fork()                            = 2169
2168  rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0
2168  rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
2168  rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
2168  nanosleep({15, 0},  <unfinished ...>
2169  getpid()                          = 2169
...
2169  execve("/mnt/sda2/ffp/opt/twonky/twonkymediaserver", ["/mnt/sda2/ffp/opt/twonky/twonkym"...], [/* 7 vars */]) = 0
2169  write(1, "TwonkyMedia Version 6.0.32\n"..., 27) = 27
2169  stat64("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=240, ...}) = 0
2169  open("/tmp/TwonkyMediaServer-log.txt", O_RDWR|O_CREAT|O_APPEND|O_LARGEFILE, 0644) = 3
2169  stat64("/tmp/TwonkyMediaServer-log.txt", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
2169  --- SIGSEGV (Segmentation fault) @ 0 (0) ---
2168  <... nanosleep resumed> 0xbe8cb988) = ? ERESTART_RESTARTBLOCK (To be rest
arted)
2168  --- SIGCHLD (Child exited) @ 0 (0) ---

The parent process 2167 seems to daemonize to process 2168, that launches 2169, the mediaserver itself, that segfaults after verifying the existence of the log file, opening it and trying to set some options; the log file itself does not appears in the filesystem, so the problem might be at stat(), although it returns success. Perhaps a compatibility problem?
The parent, that was nanosleeping, receives the dead of child signal, resumes the sleep and continues, probably relaunching the mediaserver process again.

--added: just for completeness, the sequence of calls traced when LD_LIBRARY_PATH is set to /ffp/lib is the same until the above SIGSEGV and follows with:

brk(0x265000)                           = 0x265000
brk(0x266000)                           = 0x266000
brk(0x267000)                           = 0x267000
brk(0x268000)                           = 0x268000
getuid32()                              = 0
open("/etc/passwd", O_RDONLY)           = 4
ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbed36b60) = -1 ENOTTY (Inappropriate ioctl for device)
read(4, "root:x:0:0:root:/root:/bin/sh\ndae"..., 4096) = 682
close(4)                                = 0
geteuid32()                             = 0
...
write(2, ""..., 0)                      = 0
write(2, "/mnt/sda2/ffp/opt/twonky/twonkyme"..., 42) = 42
write(2, ": can't resolve symbol '"..., 24) = 24
write(2, "atexit"..., 6)                = 6
write(2, "'\n"..., 2)                   = 2
munmap(0x40006000, 4096)                = 0
exit(1)                                 = ?

It looks like the problem is on brk(), but it succeeds in the first case a couple of calls (not shown) before the SIGSEGV.
With ffp libs atexit() is also not found and the program exits because of that.

--end of added

Using gdb is not of much help, as the twonky binaries are stripped and contains no symbols.

/tmp # gdb /mnt/sda2/ffp/opt/twonky/twonkymediaserver
GNU gdb 6.6
Copyright (C) 2006 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-unknown-linux-uclibc"...
(no debugging symbols found)
Using host libthread_db library "/ffp/lib/libthread_db.so.1".
(gdb) run
Starting program: /mnt/sda2/ffp/opt/twonky/twonkymediaserver 
(no debugging symbols found)
(no debugging symbols found)
warning: Cannot initialize thread debugging library: unknown thread_db error '22'
(no debugging symbols found)
warning: Cannot initialize thread debugging library: unknown thread_db error '22'
TwonkyMedia Version 6.0.32

Program received signal SIGSEGV, Segmentation fault.
0x000cb9dc in ?? ()
(gdb) where
#0  0x000cb9dc in ?? ()

--added: That's why I don't use closed source programs

Last edited by jcard (2011-07-22 02:27:45)

maddas wrote:

One thing I found is that I managed to get Twonky running,

You have to tell us what you did, otherwise we can't reproduce it and follow-on.

-Have you changed uclibc configuration? Changing what?
-The kernel configuration? Changing what?
-Have you used the stock firmware libraries, using LD_LIBRARY_PATH to point to them?
-How have you launched twonky?

and I could connect to it, but as soon as I added a directory any directory and it then crashed, so it may be something with the kernel?

To my knowledge, the only thing that the kernel is missing is floating point emulation, as it is not needed for Alt-F or ffp programs because their toolchains use soft-floats; FP emulation in the kernel might be needed for alien-toolchain compiled programs.