Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
Icecast-Server
Icecast-Server
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 95
    • Issues 95
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 1
    • Merge Requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • External Wiki
    • External Wiki
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Xiph.Org
  • Icecast-ServerIcecast-Server
  • Issues
  • #402

Closed
Open
Created Jul 07, 2003 by gtgbr@gtgbr

two different segfaults with statically linked icecast

My plan was to make a statically linked icecast binary, that also incorporates 
libc and friends - it's supposed to be autonomous. Note that these segfaults do 
not happen when the standard libs are dynamically linked (ogg, vorbis, libxml2 
and libxslt always being statically linked into icecast, because i don't want to 
keep the whole build environment + libs all the time in my homedir).

What I did was simply add the parameter -static to the final gcc line, when the 
binary gets linked. All libs from elsewhere and Xiph are either the latest 
release (libiconv, libxml, ...) or today's CVS (2003-07-07, ogg, vorbis, 
icecast)

#1

Built on some Redhat Linux with gcc 2.96 (blegh) and gcc 3.1 (blegh), with 
identical effect, making me believe that it's not a compiler bug for a change. 
Maybe it's a crappy libc... This segfault is minor, because it happens when the 
server is terminated with a SIGTERM, i.e. a CTRL-C. A SIGABRT doesn't trigger 
the segfault. Maybe it's a hidden memory leak as well? Here's the backtrace:

#0  0x0811b778 in chunk_free ()
#1  0x0811deed in free ()
#2  0x080c2a81 in xmlCleanupGlobals () at globals.c:49
#3  0x080882cb in xmlCleanupParser () at parser.c:11179
#4  0x0804a050 in main (argc=3, argv=0x8283080) at main.c:105
#5  0x0810a53a in __libc_start_main ()


#2

Built on a current Gentoo Linux, also against libraries in my homedir to avoid 
the -O3 -mcpu... optimizations everywhere and possible breakage that comes with 
it. This would be gcc 3.2.2. Not tested with stdlibs linked dynamically, but 
this happens when a source connects to the statically linked server, running on 
the same Redhat box from segfault #1:

#0  0x081bf7e8 in strcasecmp ()
#1  0x0805a14f in httpp_parse (parser=0x83fbb08, 
    http_data=0xbf3feacc "SOURCE /kolaradio.ogg HTTP/1.0\nAuthorization: Basic 
c291cmNlOnNpbXB1bHNlOQ==\nice-name: KOLAradio test stream\nice-genre: 
misc\nice-audio-info: samplerate=44100;channels=2;quality=1%2e00\nice-public: 
0\nic"..., len=291) at httpp.c:370
#2  0x0804ce0a in _handle_connection (arg=0x0) at connection.c:910
#3  0x080593d4 in _start_routine (arg=0x83e7b40) at thread.c:654
#4  0x0819cd3d in pthread_start_thread ()


patient: "Doctor! It hurts when I do this!"
patient: *pokes own eye* / *links statically*
doctor: "Then don't do it!"

Yeah, I know, that's why this isn't very serious. ;) I'd like to see this 
working, despite the limited use for entirely static binaries, so if someone 
finds the time to look into this, I'd appreciate that a lot.


Thanks,

Moritz
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None