Bug 74298 - cnet update from 1.7.7_2 to 2.0.9
Summary: cnet update from 1.7.7_2 to 2.0.9
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Sam Lawrance
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-11-23 17:00 UTC by Petr Holub
Modified: 2005-06-12 12:05 UTC (History)
0 users

See Also:


Attachments
cnet.patch (4.29 KB, patch)
2004-11-23 17:00 UTC, Petr Holub
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Holub 2004-11-23 17:00:47 UTC
	This is update patch for upgrading cnet to version 2.0.9. I'd like to have
	mainater look on the patch to verify, that it's correct.
Comment 1 Tilman Keskinoz freebsd_committer freebsd_triage 2004-11-23 17:16:39 UTC
Responsible Changed
From-To: freebsd-ports-bugs->arved

Take
Comment 2 Tilman Keskinoz freebsd_committer freebsd_triage 2004-11-23 17:35:17 UTC
State Changed
From-To: open->feedback

I needed to add three patches to compile this on CURRENT, please review 
http://people.freebsd.org/~arved/stuff/patch-cnet-2.0.9 

Additional the program does not ruN: 

% gdb cnet 
GNU gdb 6.1.1 [FreeBSD] 
Copyright 2004 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 "amd64-marcel-freebsd"...(no debugging symbols found)... 
(gdb) run AUSTRALIA.MAP -r 3 
Starting program: /usr/X11R6/bin/cnet AUSTRALIA.MAP -r 3 
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... 
Program received signal SIGFPE, Arithmetic exception. 
0x000000000041adf9 in __CN024 () 

Unfortunately i couldn't get a backtrace, because the port does not respect CFLAGS. 

On what Systems did you test this?
Comment 3 Tilman Keskinoz freebsd_committer freebsd_triage 2004-11-23 19:21:07 UTC
* Petr Holub [2004-11-23 19:47]:
> > Additional the program does not ruN:
> 
> BTW: the previous version didn't work for me either. Anyway - I'm
> playing with it on 5.2.1-RELEASE and I'm having the same problem.
> After some hacking in the Makefiles (to add -g and avoid stripping
> which is done in two places) and in the compiler.c (I've found that
> compiler options for cnet compilations using gcc are hard coded into
> compiler.c :(( ), I'm able to get better core .

Yes, i think the version in ports is broken too, I didn't mark it broken,
because i don't use it. But if we are two, i will mark IGNORE.

I think it would be reasonable to compile the port per default with -g and
don't touch compile.c :-).
 
> (gdb) bt
> #0  0x283cf04e in memcpy () from /lib/libc.so.5
> #1  0x0807b000 in ?? ()
> #2  0x0804d7ee in dynamic_load (n=0, so_file=0x8075b40 "./protocol.cnet")
>     at compile.c:91
> #3  0x0804d889 in __CN030 (kflag=0) at compile.c:122
> #4  0x0804ccbf in main (argc=4, argv=0xbfbfec2c) at cnetmain.c:535
> #5  0x0804afd2 in _start ()
> (gdb) up 2
> #2  0x0804d7ee in dynamic_load (n=0, so_file=0x8075b40 "./protocol.cnet")
>     at compile.c:91
> 91              data_segments(n, handle, so_file);  /* we do *not* dlclose(handl
> e) */
> (gdb) list
> 86              fprintf(stderr,"%s: cannot find %s() in \"%s\"\n", argv0,
> 87                                      NP[n].nattr.reboot_func, so_file);
> 88              ++nerrors;
> 89          }
> 90          else
> 91              data_segments(n, handle, so_file);  /* we do *not* dlclose(handl
> e) */
> 92      #endif
> 93      }
> 94
> 95
> (gdb) p n
> $1 = 0
> (gdb) p handle
> $2 = (void *) 0x2808da00
> (gdb) p so_file
> $3 = 0x8075b40 "./protocol.cnet"

I would suggest asking the author, but unfortunately he did not answer, the last time
i asked him about cnet. Maybe you have more luck.

regards
tilman
Comment 4 Petr Holub 2004-11-23 19:30:09 UTC
> I think it would be reasonable to compile the port per default with -g and
> don't touch compile.c :-).

You have to touch compile.c if you want to have .cnet files (actually shared
libs) with -g option as well. And the Makefile.common would be better not
stripping cnet binary and also we need installing it without -s option (one
more attempt to strip it).

Anyway, I will try to mail the author and we will see (and I will keep you
cc'd).

Thanks,
Petr

================================================================
                            Petr Holub
CESNET z.s.p.o.                       Supercomputing Center Brno
Zikova 4                             Institute of Compt. Science
162 00 Praha 6, CZ                            Masaryk University
Czech Republic                     Botanicka 68a, 60200 Brno, CZ
e-mail: Petr.Holub@cesnet.cz               phone: +420-549493944
                                             fax: +420-541212747
                                       e-mail: hopet@ics.muni.cz
Comment 5 Tilman Keskinoz freebsd_committer freebsd_triage 2005-05-03 18:33:54 UTC
State Changed
From-To: feedback->suspended

Suspend this PR.  
There is no solution yet, and the upstream author is unresponsive. 


Comment 6 Tilman Keskinoz freebsd_committer freebsd_triage 2005-05-03 18:33:54 UTC
Responsible Changed
From-To: arved->freebsd-ports-bugs

Back to the free pool.
Comment 7 Sam Lawrance freebsd_committer freebsd_triage 2005-06-09 15:42:02 UTC
Responsible Changed
From-To: freebsd-ports-bugs->lawrance

I'll investigate this
Comment 8 Sam Lawrance freebsd_committer freebsd_triage 2005-06-12 12:05:20 UTC
State Changed
From-To: suspended->closed

Committed with changes, thanks!
Comment 9 Sam Lawrance freebsd_committer freebsd_triage 2005-06-12 21:24:25 UTC
Okay, it seems that the problem is in src/compile/freebsd.c where
dlsym() is used to look up "end", where it should be looking up "_end".
The resulting unchecked null pointer is ultimately used to do a memcpy()
which spells trubble :-)

I'll submit this fix to the author and patch it for now.

Cheers
Sam