Sometimes I Hate Cheap eBay'ers

There are two kinds of cheap idiots out there :

• Me
• Everyone else who tries to get as much cash out of junk as they possibly can

I know, I had to be listed.

Why I'm a cheap idiot :

There are two reasons here.  If I wasn't so cheap, I would have bypassed some headlight doors on eBay, and I would have ordered the $800-per-unit ($1600 total) headlight units from the standard mail order locations (Don't go with Ecklers - I just placed an order with Corvette Central after pricing duplicate items, and found that it was still $60 cheaper with Corvette Central - and you know they get the same parts from the same suppliers).

Additionally - I failed to check the units in depth on arrival before giving them to the painter.  I DID check a few fits and other things, but failed to check for broken, damaged, or not-right things.

Why the eBay seller is a cheap idiot :

But, considering I was on a budget, trying to save pennies for potential adoptions that failed to materialize, I went with a $35 set from eBay.  They were advertised as "working condition".  That was a little fib.  What the guy failed to describe was that he was giving them up because he broke off 7 bolts and didn't want to do anything to them.

Result :

Well, considering I shipped them off to the paint shop after a cursory fit check, then installed them, I had to drill the old bolts and tap them - on the car.  That's not exactly a nice experience, sitting on cold concrete (getting polaroids) while trying to keep friction-heat from discoloring paint, or being as careful as I can to not scratch paint with spinning grinding stones, drill chucks, or tapping handles.  Trust me, it was a pain.  Here are some examples :

In the above photo, I've circled two spots.  The lower left is where a plastic clip bolts on - and the bolts were frozen (the heads snapped off).  I've already drilled and tapped the holes.  The 2nd bolt was a side bolt, and I didn't grab a picture of that - I'd already drilled, tapped, and installed the limit bracket.  The upper-right one is the bolt how where the front, surrounding bezel bolts to the lid.  I saw that, and about spit oil all over the place.  I checked the other three just to get an angle at which to drill .... only to find all four of them snapped off.  [sigh].

Make sure you do your home work, and stop trying to pass off broken as "working".  Your lies only cost people time!

Oh, and if you are having to drill and tap holes in these units, just remember, the units are soft metal, while the bolts are hard.  It's easy to go off center, and the drill bit will move to drilling the units instead of the bolds if given the chance.

Headlight Covers Installed

Well, I finally had a little time to break away from other projects and look at one that has been waiting for months, and tackle the installation of the headlight covers.  There are four painted parts - the "lid", and the "bezel".  The bezel wraps around the headlights themselves, and the "lid" is the plate above them that (when closed) is "flush" to the body lines.

To install them, you first have to get the lids in place.  There are two brackets on each end that pivot, with a lock collar to prevent the lids from sliding back and forth.  You have to get the lids in the right position (both up and down) before you tighten those brackets to the frame.  It's a pain, because those pivot brackets extend beyond the width of the hole that the lids drop into, so it has to be done at an angle, then with pressure to slide them into place.  Once that is done, you tighten the brackets while holding the lid as close to position as possible.  You can't do it with the lids in the closed position, because it doesn't allow you to reach around, hold, and tighten at the same time....  that means it's a lot of guess work.  So.... you install the lids as best you can....

.... only to find the lid doesn't close because it's too far rearward.  So.... loosen all six bolts holding that lid in place, reposition, retighten while pulling the lid forward, and let the lid down slowly....

.... only to find it's sitting too low.  Loosen them, this time pull forward and upward from those pivot points while tightening.  It was still not enough, so I had to measure around the lid to ensure I could get it centered.  Then, I removed the whole lid, then drag out the dremel grinder enlarge the holes so I could put it in (I also enlarged the wholes upward because it was still low.  Put it back in, tightened it down while pulling it forward and raising the back.

Viola!  Then I had to repeat it for the other side.

In the process, I nicked up the paint around the hole.

That means I have to touch it up tomorrow (not quite the same color, but if it's close enough, it's good enough).  I'll let that set for a couple of weeks, before I proceed to do more.  However, it does look good when I stash the bezel into position.

Woohoo!  I still need to finish it off after procuring a set screw for one of the lock collars on the left, and then it's all working on hardware inside to ensure a smooth operation.  Then, I can finally finish the electric headlight conversion!

Rebuilt: Grinder Assembly

I'm kinda glad this one was a smaller project.  It took about 8 hours of labor, stripping things down, cleaning,  priming/painting, then re-assembling.

Just a note, I couldn't (for the life of me) figure out the left side stone removal - the nut just wouldn't come off.  It took me a bit to realize it was a reverse thread, and "loosening" was actually "tightening".  Once reversed, it came right off.  Silly me!

I tried to leave the tool supports original (no refinishing, just a good brushing of the rust off), and re-threaded all of the bolts so they'd slip on easier.  I SHOULD have added washers.

The oil cups on top were plugged, so I cleaned those out, and wiped it all down before painting.  It was originally a "red", but I didn't have any of that paint laying around, so I painted it to match the lathe.  The motor is a 115v "Bendix 14080" 1/4 HP A.C. motor (not sure of the RPM it puts out) :

Sweet!

Checking the Lathe Bed Ways

On my #534.0601 Dunlap early 1940's wood lathe, I had to have the bed welded (a crack just under the ways on the tailstock end).  The welder (an older gentleman, who has been doing welding for decades) took it and brazed it.  To braze it, he ground the edges, put it over a furnace and heated it up red hot, then added material.  The problem with brazing is that it has to get red hot - which causes cast iron to warp.  On getting it back a few days ago, I knew I needed to check it for flatness to ensure things would be within specs.

However, I don't have surface for checking the plane of the ways to ensure it's not warped - meaning I thought I didn't have the tools to do it.  So, I improvised.  The next best thing was sitting in a gun case.... I had one of those laser sighting tools that sits in the chamber.  I grabbed that, threw it into the drill chuck on the headstock, and slowly adjusted it until I had it spinning without any run out (I hand turned the spindle - I didn't want it too fast).

This gave me a line-of-center from the headstock through the rest of the lathe.  I tossed on the tailstock (closer to the headstock) :

I aligned the tailstock with the laser, and then adjusted the extension on the tailstock to make sure it was lined up.  It looked great.  I slid the tailstock back a little bit, and checked it again.  I repeated this process multiple times until the last 4" of the ways - and saw some drift.  There was some slight warping from the heating.  I should have used a scraper to remove the warp, but I instead used a bastard file.  It took a couple of runs at it before it brought it back in line (it was about 0.05" off).  I am now the proud owner of a completely operational 534.0601 wood lathe with the metal turning attachment.

Memory Leak, Alarm Server, and Valgrind

Note - the output listed here comes after the process was followed, so you won't see the real memory leaks.  Sorry I didn't retain them for posterities' sake.

I had a problem.  My alarm server was having some major issues, and would stop functioning at random times.  There was no core dump to look for crossed signals (no odd null-termination things that I am used to).  However, after a little digging, I found that the process was getting sniped - meaning the Linux kernel was killing it - because it was running out of memory.  Not cool.  I didn't really know how to go about fixing the problem, so I band-aided the thing by putting a cron to reboot the device once-per-week.  I ran with it in that configuration while working on other priorities for a couple of months.  Also not cool, but it kept the security system online while I went and handled my growing project list.

So, I started researching ways to isolate the memory leaks.  One tool stood out as the best one to use (command-line based), and would work with a natively-compiled ELF binary.

Valgrind

Val grind does a lot of things, and memory leak detection is just a small slice.  I downloaded the source, and compiled and installed it (using the standard "./configure && make && make install" stuff).  I did many Google searches, and finally came up with the following command to launch the server inside of Valgrind for memory leak detection :

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --track-origins=yes --read-var-info=yes ./eventserver/server/eventserver -bf ./eventserver/server/eventserver.conf > valgrind.log 2>&;1

Essentially, I wanted to track everything related to memory interaction - I was (after all) looking for a memory leak.  I wanted to see if this would help me identify the issue.  I ran with it in this state for a while (in a screen session, to be precise) to let it build up stats.  When I hit control-C on the application to terminate, I opened up the valgrind.log file, and found a few stanzas similar to :

==12262== 891 (108 direct, 783 indirect) bytes in 9 blocks are definitely lost in loss record 86 of 93
==12262==    at 0x482CF8C: malloc (vg_replace_malloc.c:236)
==12262==    by 0xAA59: eventserver_key_set (config.c)
==12262==    by 0xAB55: eventserver_sensor_create (config.c)
==12262==    by 0x4D4DDA9: arduino_handle_request (arduino.c)
==12262==    by 0xC795: eventserver_process_hook_socket_handle_incoming (process.c)
==12262==    by 0xDC0D: eventserver_main_connection_handler (main.c)
==12262==    by 0xE29D: main (main.c)
==12262==
==12262== 65,550 bytes in 5 blocks are possibly lost in loss record 91 of 93
==12262==    at 0x482CF8C: malloc (vg_replace_malloc.c:236)
==12262==    by 0x4DA5A23: my_malloc (in /usr/lib/libmysqlclient.so.16.0.0)

Not sure what I was looking at yet, I knew it looked similar to a gdb stack trace.  The unfortunate thing was that in the traces I was looking at, it was finding things allocated using malloc, and memory pointer problems using strchr.  Since the files referenced called the functions numerous times, I didn't have much to go on.  I went back to Google, and found some additional information.  Apparently, using some compilation flags to gcc, you could add gdb debugging information, such as line numbers.  I manually added the following to the CFLAGS in all of my make files :

-g -O0

The -O0 (capital "O" and the number zero) are an optimization flag that means "don't optimize anything, seriously, leave a lot of junk in the binary" (I swear that's what it says in the man page for gcc).  The -g option means "add gdb debugger information".  You can run with a -O1, and that gets you close to the line numbers, but might not always be accurate.  However, -O0 runs molasses-slow, so use sparingly.  I thought I'd do it anyway.

I started the application again, let it run for a few days, and broke out of it once again.  This time, I had line numbers in the output.  Hallelujah!

==12262== 891 (108 direct, 783 indirect) bytes in 9 blocks are definitely lost in loss record 86 of 93
==12262==    at 0x482CF8C: malloc (vg_replace_malloc.c:236)
==12262==    by 0xAA59: eventserver_key_set (config.c:219)
==12262==    by 0xAB55: eventserver_sensor_create (config.c:256)
==12262==    by 0x4D4DDA9: arduino_handle_request (arduino.c:228)
==12262==    by 0xC795: eventserver_process_hook_socket_handle_incoming (process.c:257)
==12262==    by 0xDC0D: eventserver_main_connection_handler (main.c:494)
==12262==    by 0xE29D: main (main.c:669)
==12262==
==12262== 65,550 bytes in 5 blocks are possibly lost in loss record 91 of 93
==12262==    at 0x482CF8C: malloc (vg_replace_malloc.c:236)
==12262==    by 0x4DA5A23: my_malloc (in /usr/lib/libmysqlclient.so.16.0.0)

This was great news!  Suddenly, I could look back through the stack traces and find out where things were happening.  The application initially identified a couple hundred memory leak contexts, and a couple hundred memory errors (seen with the "definitely lost in loss record ## of ##").  On research, I realized that the vast majority of these all had a fairly similar stack trace and line number (maybe one or two lines off).  I opened that file and jumped to the line number and.....

... I had the wrong variable I was using to allocate a chunk of memory.  I made the fix, re-compiled, and had instantly narrowed down the memory error contexts to about three basic memory errors - things where I was using NULL-termination-requiring functions on variables that may not have had the termination and a MySQL error leak.  I fixed the NULL-termination errors, recompiled yet again, and had only the MySQL memory leak (appears standard with that version, which is very old). No more memory leaks!