[vdr] Re: UPT-Error related with vdr-1.1.27-1.1.28-c.diff

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Martin Holst wrote:
> 
> Klaus Schmidinger wrote:
> > Martin Holst wrote:
> > >
> > > Klaus Schmidinger wrote:
> > > > Martin Holst wrote:
> > > > [...]
> > > > > As I can see in my log, the last entry is the (Switching to channel
> > > > > 30).
> > > > > I also added some printf-statements to the main-loop of vdr and it
> > > > > seems as this loop runs several times before the segmentation fault
> > > > > occurs. Any suggestions?
> > > >
> > > > Sounds like you're dereferencing a NULL pointer.
> > > > Maybe a backtrace in gdb will tell you where this happens.
> > > >
> > > > > I think the problem is, that there are some successive changes in
> > > > > the CAM-handling between 1.1.28 and 1.2.5. Maybe it is easier to
> > > > > undo the changes in vdr 1.1.28 and check if the problem is solved.
> > > >
> > > > Yes, that may be true.
> > >
> > > Now I've undo the changes of the c-diff in vdr 1.1.28 and vd compiles
> > > without an error. But when I start vdr, I get the same segmentation
> > > fault. When I run "gdb --core=core" I get the following message:
> > >
> > > Program terminated with signal 11, Segmentation fault.
> > > #0 0x0807d161 in ?? ()
> > >
> > > A "Backtrace" shows several adresses #0-#5.
> > > Because I'm not familiar with gdb: what are the next steps to find out,
> > > in which code-fragment the problem occur?
> > > FYI: When I start vdr several times, I'll get the same list of adresses.
> >
> > Did you compile VDR with debug information?
> > by default this is the case, so unless you are using modified
> > CXXFLAGS it should give you the names of the functions that are called.
> 
> I've called a "make REMOTE=LIRC VFAT=1 NOKBD=1". I've nothing
> changed related to debugging or something in the Makefiles.
> 
> > Please post the result of a 'bt' command in gdb.
> 
> (gbd) bt
> #0 0x0807d161 in ?? ()
> #1 0x0807e2dc in ?? ()
> #2 0x080748ca in ?? ()
> #3 0x080a3b18 in ?? ()
> #4 0x40045811 in ?? ()
> 
> If it's important: I've Mandrake 9.1 with gcc 3.2.2-3mdk.

Hmm, looks like this destroys the entire stack.

I guess the only thing that will help is to throw in
some lines like

  fprintf(stderr, "%s %d\n", __FILE__, __LINE__);

around the place where you have changed something, to see
how far the program actually gets.

Klaus


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.