Bug 755795

Memory test have shown that my RAM is good in my machine.

Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please install ushare-debuginfo (debuginfo-install is from
yum-utils package).

        debuginfo-install ushare

Then stop the service (service ushare stop) and rerun (as root):

sudo -u ushare gdb /usr/bin/ushare

That will start ushare running inside of gdb debugger. Then use command

run -f /etc/ushare/

and do whatever you did to make ushare crash. When it happens, you should go back to the gdb and run

        (gdb) thread apply all backtrace

This produces usually many screens of the text. Copy all of them into a text editor and attach the file to the bug as an uncompressed attachment.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Created attachment 535058 [details]
ushare gdb backtrace -- as requested

Attached is the requested gdb backtrace of ushare.

I attached the gdb backtrace as requested.  Ran everything exactly how you asked, except the part "run -f /etc/ushare/"   that didn't work, so instead, I had to run "run -f /etc/ushare.conf"  and then it appeared to startup just fine.

(In reply to comment #4)
> I attached the gdb backtrace as requested.  Ran everything exactly how you
> asked, except the part "run -f /etc/ushare/"   that didn't work, so instead, I
> had to run "run -f /etc/ushare.conf"  and then it appeared to startup just
> fine.

Yes, that's correct sorry, it was my typo. However, the problem is that still the crash is not complete. I would be very much interested even in the part about the first frame (there is the information where actually program crashed and with what signal). Could we get complete backtrace, please?

Thank you

Created attachment 535323 [details]
script output of ushare ran in gdb

So, to make sure I included all the information, attached is the complete output (ran with script).  Double check to make sure I ran everything correctly, and advise if I didn't, and I can re-run it with any additional comments.

I can confirm this is also a problem for me, with the following packages:

ushare.1.1a-9.fc16.x86_64
libupnp.1.6.13-2.fc16.x86_64
glibc-2.14.90-19.x86_64

I am using a Sony BluRay player, model BDP-S480. I can see the share but after I connect to it, ushare segaults.

This appears in /var/log/messages:

Dec  8 16:57:38 zeus kernel: [237756.833514] ushare[10047]: segfault at 48001630 ip 00000033ded35d8c sp 00007f2d530182f8 error 4 in libc-2.14.90.so[33dec00000+1aa000]

I will attach the gdb output in just a second...

Created attachment 542641 [details]
gdb output from ushare

I got this too with my new PS3

Created attachment 546529 [details]
GDB output from second system (different than 535323)

Just figured I would attempt running this from a different system to verify if the same error occurred, and it did.

Created attachment 557079 [details]
isolated code in question

I tried to isolate and step through the code that was faulting, but when doing so the params to strncmp looked fine, and it didn't fault. Anyway, attaching in case anyone else wants to have a go.

ushare also crashes on me, with a samsung bluray player.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeedab700 (LWP 25807)]
__strncmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp.S:259
259		movdqu	(%rdi), %xmm1
(gdb) where
#0  __strncmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp.S:259
#1  0x00000000004030ff in ?? ()
#2  0x00000000004033bf in ?? ()
#3  0x0000000000403e20 in ?? ()
#4  0x000000000040b0b1 in ?? ()
#5  0x000000000040b200 in ?? ()
#6  0x00007ffff75934f3 in handle_invoke_action (info=0x7fffeedaadb0, 
    request=0x7fffeedaabc8, action_name=..., xml_doc=0x7fffd00013c0)
    at src/soap/soap_device.c:800
#7  0x00007ffff7593916 in soap_device_callback (parser=<optimized out>, 
    request=0x7fffeedaabc8, info=0x7fffeedaadb0) at src/soap/soap_device.c:874
#8  0x00007ffff75948a8 in dispatch_request (hparser=0x7fffeedaabc8, 
    info=0x7fffeedaadb0) at src/genlib/miniserver/miniserver.c:154
#9  handle_request (args=0x7fffe80023f0)
    at src/genlib/miniserver/miniserver.c:227
#10 0x00007ffff79cd421 in WorkerThread (arg=0x7ffff77adc40)
    at src/ThreadPool.c:562
#11 0x00007ffff77b6d90 in start_thread (arg=0x7fffeedab700)
    at pthread_create.c:309
#12 0x00007ffff72c2f5d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

(In reply to comment #11)
> Created attachment 557079 [details]
> isolated code in question
> 
> I tried to isolate and step through the code that was faulting, but when doing
> so the params to strncmp looked fine, and it didn't fault. Anyway, attaching in
> case anyone else wants to have a go.

#0  __strncmp_ssse3 () at ../sysdeps/x86_64/strcmp.S:213
#1  0x00000000004030ff in filter_has_val (filter=<optimized out>, val=0x40b910 "res")
    at cds.c:200


line 200 is 
if (token && !strncmp (token, val, len)) 

seems to be this strncmp , any suggestion ?

I have looking into ushare-1.1a-9.fc16.src.rpm and http://ushare.geexbox.org/

The source, ushare-1.1a is from 09-Dec-2007, and we could try development tree which have stops devel by 12-01-2009 (commit : uShare development is discontinued) 

2nd ushare.spec ./configure disable dlna with --disable-dlna 

we could try enable and use libdlna, 
we have a src.rpm in rpmfusion F-15 libdlna-0.2.3-12.fc11.src.rpm

(http://hg.geexbox.org/libdlna )

ushare seems to me very simple to use ... 

one problem that I see is libdlna depends on ffmpeg-devel and in rpmfusion we are about to update to ffmpeg-0.10

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

ushare has been retired.